mirror of
https://github.com/stablyai/orca.git
synced 2026-09-29 08:03:20 +00:00
Jinwoo Hong
83b1558ecc
* feat(mobile): time relay dial stages so diagnostics say where a slow connect went A 10s connect was unattributable from a shared report. Relay dial stages carried no timestamps, so nothing could tell "the cell never answered relay-hello" from "the E2EE handshake was slow", and the per-state dweltMs the client already computed went only to console.log — invisible without a debug build. RelayDialStageTracker now stamps each stage entry from a monotonic clock (performance.now where present, wall clock otherwise) and returns the duration of the stage it just left. The session logs one entry per stage, and settles the in-flight stage on connect, failure, or close, so a dial that dies mid-way still names the stage it never finished. dweltMs joins the same buffer as a structured field instead of console. Durations ride the existing per-host log buffer and its cap, so memory is unchanged and no new storage appears. The report derives two lines from them: the latest dial's stage breakdown (a reconnect loop must not average away the attempt being reported) and total dwell per connection state. Both are numbers and closed-enum names, and the entries still pass through the existing redaction. * fix(mobile): never let a diagnostics sink break a dial, and pin timing names to their enums Review follow-ups on the dial-stage timing work. The stage timing emitted on the confirm's success path ran inside the try that calls fail(), so an onLog sink that threw would have turned a good connect into a failed session. The same hazard existed on the direct path, where the dwell emit sits in publish() ahead of the listener loop and the connect waiters. Both sink calls are now isolated: a broken sink loses a log line and nothing else. The persisted-log validator accepted any string as a timing name, and the report echoes that name unredacted. Names are now checked against the closed enum for their kind, backed by Record<Union, true> tables so adding a stage or a state breaks the build rather than silently widening what a corrupted store can inject. Entry volume: every reconnect cycle walks four connection states, so logging each one would roughly double what a slow-connect report holds against the unchanged 200-entry per-host cap. Transitions under 100ms are therefore not buffered. They cannot be where a slow connect spent its time, and console still shows all of them. States that flap slowly, which is the case support cares about, still land in the log. RpcClientConnectionState takes an optional clock so dwell thresholds are testable without sleeping. * fix(mobile): reject a negative stored stage duration when hydrating the log A persisted timing only had to be finite to survive hydration, so a corrupted `ms: -1` reached the diagnostics report, where the dial summary sums the stage durations and a negative would subtract from the total. Producers clamp at 0 (`elapsedMs`), so anything below it is corruption. 0 itself still hydrates: a stage the dial passes through instantly is real. * refactor(mobile): move the relay liveness profile out of the session so the dial log fits * fix(mobile): never let the liveness-timeout log line keep a dead relay connected * test(mobile): prove the throwing timeout sink was actually reached