Repository navigation
feat(dgw): let a recorder push its session events log - #2117
Open
irvingouj@Devolutions (irvingoujAtDevolution) wants to merge 6 commits into
Open
irvingouj@Devolutions (irvingoujAtDevolution) wants to merge 6 commits into
irvingouj@Devolutions (irvingoujAtDevolution) wants to merge 6 commits into
Conversation
irvingouj@Devolutions (irvingoujAtDevolution)
added this pull request to stack #2120
October 19, 2026 18:07
Copilot started reviewing on behalf of
irvingouj@Devolutions (irvingoujAtDevolution)
October 19, 2026 18:43
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Token-reuse handling can reject events reconnections and concurrent clip/events startup.
2 open issues
What changed in this PR
Adds recorder-uploaded session events logs alongside recording clips, preparing for later AI enrichment.
Changes:
- Routes
artifact=eventspushes to an append-only.slogartifact. - Tracks events connections separately from clips.
- Adds lifecycle and manifest tests.
| File | Description |
|---|---|
| devolutions-gateway/src/recording.rs | Adds events-push lifecycle, append behavior, and tests. |
| devolutions-gateway/src/artifacts.rs | Adds events artifact storage and enumeration. |
| devolutions-gateway/src/api/jrec.rs | Validates and routes events push requests. |
Review effort: Balanced
Comment on lines
+935
to
+936
| self.events_pushes.insert(id); | ||
| self.rx.active_recordings.insert(id); |
Comment on lines
+944
to
+945
| if !self.ongoing_recordings.contains_key(&id) { | ||
| self.rx.active_recordings.remove(id); |
irvingouj@Devolutions (irvingoujAtDevolution)
force-pushed
the
feat/recording-events-push
branch
from
October 19, 2026 21:01
fe2fd0a to
0a3ff45
Compare
A recorder can now push a session events log (`.slog`) next to its
recording stream, over the same push WebSocket:
/jet/jrec/push/{id}?fileType=slog&artifact=events
The log is listed under `artifacts.events` in the manifest, not in
`files`, so it stays out of the clip list, the shadow stream and the
recording policy. A reconnecting recorder appends to the same log. The
session stays active (token reuse, delete conflict) while either push
is connected.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ame first An events push that connects before any clip creates the manifest, with its own connect time as the session start. The first clip now resets that start, so `startTime` and `duration` describe the recording, not the wait for it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
An open events push kept the session in the active recordings, so the push token stayed reusable for new clips past its reconnect window, until it expired. The events push now leaves the recording state alone. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The events push created the session folder and manifest when it came before the recording, and the first clip then had to reset the session start for it. The folder and manifest belong to the recording: an events push now needs the recording of the session to have started, and is refused before. The events push has its own push token, separate from the recording's, so an events push refused this way never touches the recording's token. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
… untested - The push logs say whether a clip or the events log started or ended. - The append of a reconnecting events push has no test; an `UNTESTED:` comment keeps it from turning into a truncate. - `handle_connect_events` no longer awaits anything, so it is not async. - The test waiting for a recording to end gives up after 5 s instead of hanging. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
irvingouj@Devolutions (irvingoujAtDevolution)
force-pushed
the
feat/recording-events-push
branch
from
October 19, 2026 21:15
0a3ff45 to
3c50ce2
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

A recorder can now push a session events log (
.slog) next to its recording, on the existing push route, with a push token of its own (samejet_aid, its ownjti):The log goes under
artifacts.eventsinrecording.json, not infiles. So clips, the shadow stream, the recording policy and remux don't change. Withoutartifact, a push works like today.events-0.slog, while its token can still be reused: same source IP, and the recording push still active or in its reconnect window.?active=truelisting work exactly like today.The AI analysis (#2044) only reads the
localeof this log; it writes its ownai-analysis-0.slog.Where to look hardest:
handle_connect_events/handle_disconnect_eventsinrecording.rs, and that nothing else of the recording readsevents_pushes.Tests: unit tests in
recording.rsfor each case above.🤖 Generated with Claude Code