Repository navigation
feat(webapp): push the session events log next to the recording - #2119
irvingouj@Devolutions (irvingoujAtDevolution) wants to merge 5 commits into
Conversation
`SessionEventsRecorder` pushes the session events log (`.slog`) over
`/jet/jrec/push/{id}?fileType=slog&artifact=events`: `session.start`,
with the session `locale` and `mediaStartTime`, when it starts, and
`session.end` when it stops. The AI analysis of Gateway adds what the
user did to this log, in that locale, on the media timeline.
`WebMRecorder` and `AsciiCastV2Recorder` expose `mediaStartTime`, the
moment their media starts on the browser clock. Start the events
recorder after the media recorder, so a Gateway without events logs
only refuses the events push.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Let maintainers know that an action is required on their side
|
There was a problem hiding this comment.
🟡 Changes recommended
Startup cancellation, reconnect sequencing, and failure reporting have unresolved correctness issues.
3 open issues
What changed in this PR
Adds session-event recording alongside media uploads, using Gateway’s events-artifact support from #2117.
Changes:
- Adds
SessionEventsRecorderto send session start/end events and timeline metadata. - Exposes media start times from both media recorders.
- Exports the new recorder and options.
| File | Description |
|---|---|
webapp/packages/web-recorder/src/webm-recorder.ts |
Tracks and exposes video start time. |
webapp/packages/web-recorder/src/session-events-recorder.ts |
Uploads session lifecycle events over WebSocket. |
webapp/packages/web-recorder/src/index.ts |
Exports the session-events API. |
webapp/packages/web-recorder/src/asciicast-v2-recorder.ts |
Exposes terminal recording start time. |
Review effort: Balanced
| return; | ||
| } | ||
| this.ws = ws; | ||
| this.seq = 0; |
| ws.onerror = ws.onclose = () => { | ||
| if (this.ws !== ws) return; | ||
| this.ws = null; | ||
| reject('UnableToConnectToTheRecordingServer'); |
| this.ws = null; | ||
| ws.onopen = null; | ||
| ws.onerror = null; | ||
| ws.onclose = null; |
Restarting the same `SessionEventsRecorder` continues `seq`, since a viewer orders the log by `seq` and two runs from 0 would interleave. The docs say which refusals still come after `start()` resolves. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- Stopping before the events push opens resolves its start, which never settled before. - A bad push URL or media start time rejects the start instead of throwing or hanging. - `isRecording` tells when Gateway or the network ended the push, and an unexpected end is logged. - The docs say Gateway's session checks end the push after the start resolves, and that an older Gateway refuses it only while the media push is connected. - `WebMRecorder.mediaStartTime` returns a copy, like the asciicast one. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Adds
SessionEventsRecorderto@devolutions/web-recorder. It pushes the session events log next to the recording:session.startwithlocaleandmediaStartTimewhen it startssession.endwhen it stopsIt uses
/jet/jrec/push/{id}?fileType=slog&artifact=events, on a push URL with its own push token, never the media recorder's. Gateway never changes this log. Its AI analysis is a separate log written in that locale;mediaStartTimelets a caller put both on the media timeline.WebMRecorderandAsciiCastV2Recordernow exposemediaStartTimeso the caller can pass it in. Start the events recorder after the media recorder: Gateway refuses an events push before the recording starts, and an older Gateway refuses only the events push while the media push is connected. Gateway checks the session once the socket is open, so such a refusal resolvesstart()and then ends the push;isRecordingtells.Needs the Gateway side: #2117.
Tests: tsc and biome only, no browser test.
🤖 Generated with Claude Code