Move trial analytics tracking to server-side#4117
Conversation
✅ Deploy Preview for hyprnote-storybook canceled.
|
✅ Deploy Preview for hyprnote canceled.
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 4 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| if let Some(last) = promoted.last() { | ||
| self.watermark = self.watermark.max(last.end_ms); | ||
| } | ||
| finalize_words(to_finalize, id_gen) |
There was a problem hiding this comment.
Pre-final partials emitted before held word breaks ordering
High Severity
In apply_final, promoted pre-final partials are placed into to_finalize before the emitted words from stitch. The stitch function prepends the previously held word (from an earlier final batch) to the front of its emitted output. Since the held word chronologically precedes the pre-final partials, the resulting to_finalize vector is out of chronological order: [partials..., held_word, final_words...] instead of [held_word, partials..., final_words...]. Because finalize_words does not sort, the consumer receives out-of-order transcript words.
| pending_text: String, | ||
| pending_language: Option<String>, | ||
| pending_confidence: f64, | ||
| pending_cloud_job_id: u64, |
There was a problem hiding this comment.
Field pending_cloud_job_id is written but never read
Low Severity
The pending_cloud_job_id field on ChannelState is set (line 189) and cleared (line 230) but never read anywhere in the codebase. It appears intended for future validation (e.g., matching cloud_result_job_id against the pending value) but currently serves no purpose and is dead code.
Additional Locations (2)
| Some(keys) | ||
| } else { | ||
| None | ||
| }; |
There was a problem hiding this comment.
Duplicated handoff extra HashMap construction code
Low Severity
The handoff_extra (line 248) and pending_handoff_extra (line 324) blocks are byte-for-byte identical — same condition, same HashMap keys and values. Since the confirmed-text branch returns early at line 298, only one of these is ever used per invocation. Computing it once before the branch point and reusing the single variable would eliminate the duplication.
Additional Locations (1)
| return LoopAction::Break; | ||
| } | ||
| state.pending_cloud_job_id = 0; | ||
| } |
There was a problem hiding this comment.
Cloud result uses overwritten segment start from new handoff
High Severity
The cloud handoff block (lines 188–191) overwrites cloud_handoff_segment_start before the cloud result block (lines 193–231) reads it. When a single StreamResult contains both a new cloud_handoff and a completed cloud_result from a previous job, line 196 reads the segment start of the new handoff instead of the old one. This produces a cloud correction transcript with the wrong start and duration. Swapping the two if blocks so the cloud result is processed first would fix it.
1 participant
ToAnalyticsPayloadtrait andPropertiesPayloadBuilderto analytics crateSubscriptionConfig::with_analyticsto inject analytics into the subscription servicestripe.rsand trial types/response logic intotrial.rsToAnalyticsPayloadforTrialOutcometo emittrial_started/trial_skipped/trial_failedevents with properties server-sidelogin.tsx,account.tsx)StreamResponse::set_extrato merge extra metadata instead of replacing ituser_signed_inevents fired on token auto-refreshMade with Cursor