Problem
Debugging across the RVT1 bridge is materially worse than duplicated native logic — the Taskly migration doc names exactly this as a declared stop condition, and the Sep 21 slog confirmed it: Racket-side exceptions die as opaque process exits on the native side, and there is no wire-level trace to see what the last exchange was.
Proposed fix
- structured error propagation: a Racket exception raised inside an RPC handler crosses RVT1 as a typed error record (message, kind, racket-side context/stack summary) instead of tearing down the channel; native clients surface it as a typed error object
- verbose trace mode:
raco rivet dev --trace (or env flag) logging each RVT1 frame (method, arg sizes, result size, duration) to stderr — enough to answer "did the call leave the native side? did the backend answer?"
Both are additive to RVT1 v1 and compatible with the keep-the-v1-decoder rule.
RIVET-LIB-BACKLOG item 7 (P2).
Problem
Debugging across the RVT1 bridge is materially worse than duplicated native logic — the Taskly migration doc names exactly this as a declared stop condition, and the Sep 21 slog confirmed it: Racket-side exceptions die as opaque process exits on the native side, and there is no wire-level trace to see what the last exchange was.
Proposed fix
raco rivet dev --trace(or env flag) logging each RVT1 frame (method, arg sizes, result size, duration) to stderr — enough to answer "did the call leave the native side? did the backend answer?"Both are additive to RVT1 v1 and compatible with the keep-the-v1-decoder rule.
RIVET-LIB-BACKLOG item 7 (P2).