@voltro/client 0.60.0 → 0.62.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -39,6 +39,49 @@ _Changes staged for the next release accumulate here (rolled up from
39
39
 
40
40
  ---
41
41
 
42
+ ## [0.62.0] — 2026-09-01
43
+
44
+ ### ⚠ BREAKING
45
+
46
+ - **@voltro/workflow, @voltro/cli, @voltro/voltro** — `timeouts.finish` now filters running rows by the declared workflow, durably cancels each run before notification, and emits `onFailure` only for the successful terminal transition. Finish-timeout reports carry the run's stable `runId`, `executionId`, and original payload; handler-start logs expose the returned status instead of unconditionally claiming a new start.
47
+
48
+ Low-level adapters that construct `AdmissionDrainDeps` must update `cancelRun` to accept the run object and return whether it made the terminal transition, and return the run identity, workflow name, and payload from `listRunningRuns`. Ordinary workflow declarations need no source change; `voltro update` prints the adapter migration only when the project references this low-level surface.
49
+
50
+ ### Added
51
+
52
+ - **@voltro/ai** — `streamText` and `resumableStreamText` now accept an opt-in `smooth` configuration for word- or line-based text and reasoning chunks. Smoothing runs before resumable journaling, preserves provider-native behavior when omitted, and shares the stream abort signal so cancellation also stops a pending smoothing delay.
53
+
54
+ ### Fixed
55
+
56
+ - **@voltro/web** — Production `framework_debug` now enables local framework diagnostics without opening browser-to-inspect HTTP or SSE transports. Development log relays are single-flight and rate-limited, classify permanent response failures, back off transient failures, expose dropped-log counts, and open a page-scoped circuit after repeated failure; the SSE relay also probes the endpoint before creating an `EventSource` and closes failed sources before retrying.
57
+
58
+ ---
59
+
60
+ ## [0.61.0] — 2026-08-31
61
+
62
+ ### ⚠ BREAKING
63
+
64
+ - **@voltro/client, @voltro/web, @voltro/cli** — `RpcError.kind` now distinguishes transport, handler, client, and unknown failures; manually emitted events must add the field, while `useConnectionStatus` now degrades only for transport failures and clears on the next rpc success.
65
+
66
+ **`voltro update` carries you across this** — codemod `0.61.0/01_rpc_errors_have_kinds`. If you pin versions by hand and never run it, print the notes without changing anything: `voltro update --codemods-only --from <your current version> --dry-run` (this one ships in 0.61.0).
67
+ - **@voltro/plugin-sentry, @voltro/cli** — Browser RPC spans now join the active page/navigation transaction and link to the Effect/server trace instead of creating one root transaction per call; `tracesSampleRate`, `browserTracing`, and the new `rpcSpans` switch control the resulting browser trace volume.
68
+
69
+ **`voltro update` carries you across this** — codemod `0.61.0/02_sentry_rpc_spans_join_page`. If you pin versions by hand and never run it, print the notes without changing anything: `voltro update --codemods-only --from <your current version> --dry-run` (this one ships in 0.61.0).
70
+
71
+ ### Fixed
72
+
73
+ - **@voltro/cli** — **Six SSR failure sites report to Sentry, not three.**
74
+
75
+ 0.60.0 gave the web server its own Sentry and wired the three loud sites: the SSR shell throw, the SPA layout shell throw, and the general render error (which covers a loader throw). The docs said "shell throw, loader throw, PPR/SWR refresh" — and an enumeration in a claim is read as exhaustive.
76
+
77
+ The other three were `warn`-level and reported to nobody: a failed PPR hole pass, a failed background SWR refresh, and a `not-found.tsx` that throws while rendering. They are quieter because the request still serves something — stale HTML, an unfilled hole, a plain 404 — which says something about the REQUEST and nothing about who else could find out. The answer to that is nobody: none of them reaches a browser boundary, so the pod's stdout was the only record.
78
+
79
+ They carry their own `voltro.stage` (`not-found-render`, `ppr-holes`, `swr-refresh`), so a quota-conscious project can drop them by stage without losing the three that fail the request.
80
+
81
+ `webSentry.test.ts` now fails if a render-path `log.error`/`log.warn` gains no reporter beside it — the property, rather than the six call sites.
82
+
83
+ ---
84
+
42
85
  ## [0.60.0] — 2026-08-31
43
86
 
44
87
  ### ⚠ BREAKING
package/dist/index.d.ts CHANGED
@@ -602,8 +602,8 @@ export declare interface ClientTraceEvent {
602
602
  /** W3C trace id (32 hex) of the call the client just started. */
603
603
  readonly traceId: string;
604
604
  /** W3C span id (16 hex) of the client span — the parent the server
605
- * continues from. Lets a vendor integration (Sentry) place the
606
- * browser-side span in the SAME trace tree as the server transaction. */
605
+ * continues from. Lets a vendor integration correlate browser work to the
606
+ * server trace without changing the browser span's page-owned parent. */
607
607
  readonly spanId: string;
608
608
  /** `'mutation'` | `'action'` | `'subscription'` — which surface started it. */
609
609
  readonly source: 'mutation' | 'action' | 'subscription';
@@ -686,7 +686,7 @@ export declare interface ConnectionState {
686
686
  readonly status: ConnectionStatus;
687
687
  /** `navigator.onLine` (true during SSR — nothing better is knowable there). */
688
688
  readonly online: boolean;
689
- /** Consecutive rpc failures with no success in between. 0 when healthy. */
689
+ /** Consecutive transport failures with no server response or rpc success in between. */
690
690
  readonly failureCount: number;
691
691
  /** When the most recent failure was observed. */
692
692
  readonly lastFailureAt: number | undefined;
@@ -2497,10 +2497,14 @@ export declare interface RpcError {
2497
2497
  /** The raw error value. May be a Schema.TaggedError instance, a plain
2498
2498
  * Error, an unknown thrown value. Pattern-match on `_tag` for typed errors. */
2499
2499
  readonly error: unknown;
2500
- /** Trace id of the failed call the SAME id the server logged + the
2501
- * dashboards show. Lets a listener (or `DefaultErrorFallback`) point at
2502
- * `voltro logs --trace <id>`. Present when a client span was active
2503
- * (always, in practice — Effect's native tracer is ambient). */
2500
+ /** Failure origin. Use `transport` for connection-level UX; `handler` means
2501
+ * the rpc returned a declared failure; `client` is framework work that
2502
+ * failed locally; `unknown` is deliberately unclassified. */
2503
+ readonly kind: RpcErrorKind;
2504
+ /** Trace id of the CLIENT call span. When the server accepted the request,
2505
+ * @effect/rpc propagates this same id into its span. A transport failure may
2506
+ * happen before that, so the id is not proof that server logs exist. Present
2507
+ * only when a client span was active. */
2504
2508
  readonly traceId?: string;
2505
2509
  }
2506
2510
 
@@ -2542,6 +2546,12 @@ export declare class RpcErrorBus {
2542
2546
  emitSuccess(event: RpcSuccess): void;
2543
2547
  }
2544
2548
 
2549
+ /** Where the failure originated, classified only as far as the client can
2550
+ * prove. In particular, `transport` does NOT mean the server definitely saw
2551
+ * nothing: a connection can disappear after a request was accepted but before
2552
+ * its response reached the browser. */
2553
+ export declare type RpcErrorKind = 'transport' | 'handler' | 'client' | 'unknown';
2554
+
2545
2555
  export declare type RpcErrorListener = (event: RpcError) => void;
2546
2556
 
2547
2557
  /** A call that SUCCEEDED. Carries only its source and tag — there is no payload
@@ -3931,10 +3941,10 @@ export declare const useConnections: (apiName: string) => ConnectedAccountsContr
3931
3941
  * {status !== 'connected' && <OfflineBanner status={status} />}
3932
3942
  * ```
3933
3943
  *
3934
- * `degraded` clears as soon as any rpc on that api succeeds again call
3935
- * `reportSuccess()` from a place that knows a call went through if you want to
3936
- * clear it eagerly (the hook already clears it when the browser comes back
3937
- * online).
3944
+ * `degraded` clears as soon as any rpc on that api succeeds or returns a
3945
+ * declared handler failure both prove a server round trip. Call
3946
+ * `reportSuccess()` when another signal proves reachability (the hook also
3947
+ * clears when the browser comes back online).
3938
3948
  */
3939
3949
  export declare const useConnectionStatus: (apiName: string) => ConnectionState & {
3940
3950
  /** Clear the degraded state — call after a known-good round trip. */