[ChakraFusion]

The next standalone part of the play-sessions draft (#34), rebuilt on dev-public without save versions.

The problem. A game autosaves every few minutes, and each autosave was synced as it came. One afternoon, a device took eleven versions of one game in 26 minutes from the device it was being played on, each with its own "synced from another device" snapshot. The playing device snapshotted every autosave too. The gameplay guard only waits while save files are locked, and many games don't keep them locked. And a device took other devices' versions of a game running on it, writing a save under the game.

The change (syncengine/playing.go, daemon/sessions.go). While a game is being played on a device (the daemon's play sessions):

• it isn't synced either way there: SyncGame declines quietly (ErrPlayingHere, which counts as ErrHeld);
• another device asking for it, for its manifest or for deletions, is answered "playing". That device says so once per session instead of failing. The answer contains SettlingMessage, so an older build takes it as "busy, ask again";
• the watcher snapshots a change to it at most once per 30 minutes, so a crash still leaves a recent copy.

When the session ends, the existing "After playing" snapshot is taken and the save goes to the other devices in one sync.

A session must end when the game does (second commit), since it now holds the save. A process named like the game stayed behind for fifteen minutes after one closed, with under 1 MB and no processor time; a killed one left two that kept their memory and used none. On Windows, processes are now measured (memory and processor time). One holding under 32 MB that used no processor time since the last poll, or one that used none for a minute whatever it holds, is not the game. A game being played uses some all the time; a paused one still draws its menu. A process that can't be measured still counts.

Tests:

• syncengine: TestPlaying_NotSyncedWhilePlayedHere, TestPlaying_PeerPlayingIsWaitedFor
• daemon: checkpoint timing, TestSessionEndsWhenOnlyAStubIsLeft (fails without the idle filter), TestActiveProcesses_HoldingMemoryDoingNothing
• sessions: TestIdle

Left for a follow-up (P2): finding a running game wherever it is installed, and protected games whose path can't be read.

Checks: the full unit and e2e suites pass locally on today's dev-public.

🤖 Generated with Claude Code

[vercel]

@ChakraFusion is attempting to deploy a commit to the sivadaboi's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Omar-VF]

Thanks, this reads well, and it fits with the Deck plugin's play sessions (#109). One question on idleFor: a game minimised in the background can throttle to almost nothing, and some suspend outright. If one used no processor time for a minute, its session would end while it's still running, and the save would be synced under it, which is the case this PR is there to stop. Would a longer quiet period (a few minutes) still catch the stubs you saw, which lingered for fifteen?

[ChakraFusion]

Good point, and it went further than idleFor. The other rule, under 32 MB with no processor time since the last poll, could also end a minimised game's session: Windows trims a minimised program's working set. Done in e49b0b1: there is one rule now. A process that has used no processor time for five minutes is not the game, whatever memory it holds, and memory is no longer read. That still lets go of the stubs I saw (they lingered about fifteen minutes).

This makes it the intended behaviour: a game that has used no processor time for five minutes is taken as not being played, its session ends and the save syncs, so nothing a game leaves behind can hold the save back for longer. A game in the background that still ticks over keeps its session.

One gap was left: a leftover process that keeps using a little processor time (a crash reporter, a launcher helper) would keep the session, and the hold on the save, open indefinitely. Closed in af64c5b and 9d4ecb1: a session found from running processes is taken as over when, for an hour, its save hasn't changed and the game's processes used under 1% of one core (about 36 seconds). It's then kept and synced as when the game closes. The process still there doesn't start it again; the save changing again does. Two cases are deliberately left alone:

• A game saved only by hand can go hours without saving while it's played, but it keeps drawing and uses far more than that, so its session goes on.
• A session begun from outside (the Deck plugin from Steam's launch in Deck: a game's start waits for its save, and its play is told to the daemon #109, opensave wrap) is never ended this way: what began it says when it ends.

What's left is a game paused and minimised for over an hour, throttled under 1% and not saving. Its session ends and its save is kept and synced. If another device changes the save meanwhile, the user is asked when they come back and save.

Tests:

• TestActiveProcesses_QuietForLongIsNotTheGame: a quiet game still counts at 70 seconds and at 4 minutes, and not after 5. It fails at both under the old one-minute rule.
• TestQuietSession_ALeftoverThatTicksOverIsLetGo: a leftover that ticks over is let go after the hour.
• TestQuietSession_AGamePlayedWithoutSavingKeepsItsSession and TestQuietSession_ASessionBegunFromOutsideIsNotEnded: a game played three hours without saving keeps its session, and so does a Deck session. Both fail under the hour alone.

🤖 Generated with Claude Code

[Omar-VF]

Thanks, the new rules read well: five minutes without processor time, the hour-long backstop only for nearly idle sessions found from running programs, and outside sessions left alone. We'd like to merge it. It now conflicts with #114 (just merged) in SyncGame's status switch: both add a result to the case "conflict", "error", … line. Keeping both ("unwritable" and "peer_playing") is all it needs. Please rebase.

[ChakraFusion]

Thanks! Done in d2161e4: today's dev-public is merged in, and the line keeps both, case "conflict", "error", "unwritable", "peer_playing":. GitHub shows it mergeable. I merged rather than rebased to keep the review history; happy to rebase instead if you prefer.