Skip to content

fix(rivekit): stub traces in browser#4120

Closed
jog1t wants to merge 1 commit intomainfrom
02-05-fix_rivekit_stub_traces_in_browser
Closed

fix(rivekit): stub traces in browser#4120
jog1t wants to merge 1 commit intomainfrom
02-05-fix_rivekit_stub_traces_in_browser

Conversation

@jog1t
Copy link
Contributor

@jog1t jog1t commented Feb 5, 2026

Description

Added browser-specific exports for the @rivetkit/traces package to ensure proper bundling in browser environments. This change:

  1. Created a browser-specific entry point (index.browser.ts) that provides a stub implementation of createTraces() which throws an appropriate error when called in browser contexts
  2. Updated the package.json to include browser-specific export conditions for all entry points
  3. Reorganized imports in frontend components to use the correct paths and avoid importing server-only code in the browser
  4. Consolidated type imports to come from their appropriate modules

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

Verified that the frontend components can properly import the trace-related types and functions without pulling in server-only code.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes

Copy link
Contributor Author

jog1t commented Feb 5, 2026


How to use the Graphite Merge Queue

Add the label merge-queue to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

@claude
Copy link

claude bot commented Feb 5, 2026

PR Review: Browser-specific exports for @rivetkit/traces

Overview

This PR adds browser-specific exports to prevent bundlers from pulling server-only Node.js dependencies into browser bundles. The approach is solid and follows established patterns for creating platform-specific builds.


✅ Strengths

  1. Clean separation of concerns: The browser stub (index.browser.ts) clearly documents why it exists and what dependencies it avoids (node:async_hooks, node:crypto, fdb-tuple)

  2. Proper error messaging: The stub throws a descriptive error if createTraces() is accidentally called in a browser context

  3. Export conditions: Package.json correctly uses the "browser" condition which modern bundlers (Vite, Webpack 5+, etc.) will respect

  4. Type safety maintained: Browser exports include types, so TypeScript will still work correctly in browser contexts


🔍 Issues & Concerns

1. Missing type exports in browser stub (High Priority)

The index.browser.ts only exports createTraces() but the main index.ts exports many types:

// From index.ts - these are missing in index.browser.ts
export type {
  EndSpanOptions, EventOptions, ReadRangeOptions, ReadRangeResult,
  ReadRangeWire, SpanHandle, SpanStatusInput, StartSpanOptions,
  Traces, TracesDriver, TracesOptions, UpdateSpanOptions
} from "./types.js";
export type { OtlpAnyValue, OtlpExportTraceServiceRequestJson, ... } from "./otlp.js";

Why this matters: Frontend code imports these types (see frontend/src/components/actors/actor-traces.tsx:24-30). The browser build will fail type resolution if these aren't re-exported from index.browser.ts.

Fix: Add all type exports to index.browser.ts:

export function createTraces(): never {
  throw new Error("...");
}

// Re-export all types that browser code needs
export type {
  EndSpanOptions, EventOptions, ReadRangeOptions, ReadRangeResult,
  ReadRangeWire, SpanHandle, SpanStatusInput, StartSpanOptions,
  Traces, TracesDriver, TracesOptions, UpdateSpanOptions
} from "./types.js";
export type {
  OtlpAnyValue, OtlpExportTraceServiceRequestJson, OtlpInstrumentationScope,
  OtlpKeyValue, OtlpResource, OtlpResourceSpans, OtlpScopeSpans,
  OtlpSpan, OtlpSpanEvent, OtlpSpanLink, OtlpSpanStatus
} from "./otlp.js";

2. Missing ./reader export browser condition (Medium Priority)

The package.json defines "./reader" as a subpath export but doesn't provide browser-specific handling:

"./reader": {
  "import": { "types": "./dist/tsup/reader.d.ts", "default": "./dist/tsup/reader.js" },
  "require": { ... }
}

The readRangeWireToOtlp function from ./reader is used in browser code (actor-traces.tsx:23). If reader.ts has Node.js-only dependencies, this needs the same browser treatment.

Investigation needed: Check if src/reader.ts uses Node.js APIs. If so, add browser condition.

3. No test coverage verification (Medium Priority)

The PR description mentions "added tests" but the diff shows no test file changes. Consider:

  • Unit test verifying the browser stub throws correctly
  • Integration test ensuring types resolve properly in browser builds
  • Build test confirming no Node.js modules leak into browser bundle

4. Minor: Dependency reordering (Low Priority)

The diff shows cbor-x and fdb-tuple swapped order in dependencies. While harmless, this appears unintentional and adds noise to the diff.


🧪 Testing Recommendations

  1. Verify browser build: Run the frontend build and check that no Node.js modules are in the bundle:

    pnpm --filter frontend build
    # Check bundle for node:async_hooks, node:crypto, fdb-tuple references
  2. Type checking: Ensure TypeScript resolves types correctly in browser contexts:

    pnpm --filter frontend check-types
  3. Runtime test: Add a test that imports @rivetkit/traces in a browser environment and verifies:

    • Type imports work
    • Calling createTraces() throws the expected error

📋 Additional Considerations

  1. Documentation: Consider adding a note to the package README explaining the browser/server split for future maintainers

  2. Tree-shaking: With the browser stub only exporting a function that throws, dead code elimination should remove it entirely if unused. Verify this works as expected.

  3. Future exports: If adding new functions/types to index.ts, remember to update index.browser.ts appropriately (types should be added, server-only functions should be stubbed)


🎯 Action Items

Must fix before merge:

  • Add all type exports to index.browser.ts
  • Verify ./reader subpath export doesn't need browser handling
  • Test that browser builds work and types resolve correctly

Nice to have:

  • Add unit/integration tests
  • Document browser/server split
  • Revert unintentional dependency reordering

Summary

The core approach is excellent and solves the bundling problem correctly. The main issue is incomplete type exports in the browser stub, which will cause TypeScript errors in browser contexts. Once the types are added and verified, this should be good to merge.

@pkg-pr-new
Copy link

pkg-pr-new bot commented Feb 5, 2026

More templates

@rivetkit/cloudflare-workers

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/cloudflare-workers@4120

@rivetkit/db

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/db@4120

@rivetkit/framework-base

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/framework-base@4120

@rivetkit/next-js

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/next-js@4120

@rivetkit/react

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/react@4120

rivetkit

pnpm add https://pkg.pr.new/rivet-dev/rivet/rivetkit@4120

@rivetkit/sql-loader

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/sql-loader@4120

@rivetkit/traces

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/traces@4120

@rivetkit/workflow-engine

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/workflow-engine@4120

@rivetkit/virtual-websocket

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/virtual-websocket@4120

@rivetkit/engine-runner

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/engine-runner@4120

@rivetkit/engine-runner-protocol

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/engine-runner-protocol@4120

commit: 73b4513

@graphite-app
Copy link
Contributor

graphite-app bot commented Feb 5, 2026

Graphite Automations

"Test" took an action on this PR • (02/05/26)

1 assignee was added to this PR based on Kacper Wojciechowski's automation.

@graphite-app graphite-app bot force-pushed the 01-28-feat_dashboard_traces_timeline_ui branch from a18121c to f49653b Compare February 5, 2026 00:40
@graphite-app graphite-app bot force-pushed the 02-05-fix_rivekit_stub_traces_in_browser branch from 55c8a8a to 73b4513 Compare February 5, 2026 00:41
Comment on lines 2 to 9
import {
readRangeWireToOtlp,
type OtlpAnyValue,
type OtlpExportTraceServiceRequestJson,
type OtlpKeyValue,
type OtlpSpan,
type OtlpSpanEvent,
} from "@rivetkit/traces/otlp";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Import sorting issue. The imports were reorganized but may not follow the project's convention. Run the Biome formatter to fix this automatically.

Spotted by Graphite Agent (based on CI logs)

Fix in Graphite


Is this helpful? React 👍 or 👎 to let us know.

Comment on lines 71 to +72
"fdb-tuple": "^1.0.0",
"cbor-x": "^1.6.0",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dependency ordering issue. The 'cbor-x' dependency was moved after 'fdb-tuple' which might violate the project's dependency sorting rules. Dependencies should be alphabetically sorted.

Spotted by Graphite Agent (based on CI logs)

Fix in Graphite


Is this helpful? React 👍 or 👎 to let us know.

@NathanFlurry NathanFlurry changed the base branch from 01-28-feat_dashboard_traces_timeline_ui to graphite-base/4120 February 5, 2026 08:34
@jog1t jog1t force-pushed the graphite-base/4120 branch from f49653b to 7bb6306 Compare February 5, 2026 20:34
@jog1t jog1t force-pushed the 02-05-fix_rivekit_stub_traces_in_browser branch from 73b4513 to 464d190 Compare February 5, 2026 20:34
@jog1t jog1t changed the base branch from graphite-base/4120 to main February 5, 2026 20:34
@jog1t jog1t mentioned this pull request Feb 5, 2026
11 tasks
@graphite-app
Copy link
Contributor

graphite-app bot commented Feb 5, 2026

Merge activity

  • Feb 5, 10:06 PM UTC: jog1t added this pull request to the Graphite merge queue.
  • Feb 5, 10:06 PM UTC: CI is running for this pull request on a draft pull request (#4129) due to your merge queue CI optimization settings.
  • Feb 5, 10:07 PM UTC: Merged by the Graphite merge queue via draft PR: #4129.

graphite-app bot pushed a commit that referenced this pull request Feb 5, 2026
# Description

Added browser-specific exports for the `@rivetkit/traces` package to ensure proper bundling in browser environments. This change:

1. Created a browser-specific entry point (`index.browser.ts`) that provides a stub implementation of `createTraces()` which throws an appropriate error when called in browser contexts
2. Updated the package.json to include browser-specific export conditions for all entry points
3. Reorganized imports in frontend components to use the correct paths and avoid importing server-only code in the browser
4. Consolidated type imports to come from their appropriate modules

## Type of change

- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] This change requires a documentation update

## How Has This Been Tested?

Verified that the frontend components can properly import the trace-related types and functions without pulling in server-only code.

## Checklist:

- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my code
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [x] I have added tests that prove my fix is effective or that my feature works
- [x] New and existing unit tests pass locally with my changes
@graphite-app graphite-app bot closed this Feb 5, 2026
@graphite-app graphite-app bot deleted the 02-05-fix_rivekit_stub_traces_in_browser branch February 5, 2026 22:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant