Re-running one of two parallel jobs restores the sibling's snapshot and loses its session #1778

Activity

1. fro-bot

   added

   agent: working

   on Oct 10, 2026
2. fro-bot commented on Oct 10, 2026

   

   fro-bot

   on Oct 10, 2026

   Owner

   More actions

   Confirmed locally: parallel jobs save distinct snapshots, but re-running the earlier-saving job restores its sibling’s snapshot and loses session continuity. Its original cache entry still exists; restore selects the wrong one.

   Reproduction

   Used the real saveCache/restoreCache functions, isolated SQLite session fixtures, and an injected cache adapter modeling GitHub’s ordered, newest-prefix matching:

   1. Two runners begin with the same empty history.
   2. fro-bot saves its session; fro-bot-remediate independently saves its own session afterward.
   3. Re-run fro-bot with the same run ID and attempt 2.
   4. Restore reports a cache hit on …-38026680860-1-fro-bot-remediate; the requested fro-bot session is absent.

   This produced the expected continuity assertion failures for both schedule and workflow_dispatch. Re-running the later-saving sibling passed in both cases. The existing cache-key/invocation-identity suites also passed (21 tests). This was a local adapter-based reproduction, not a live parallel Actions run.

   Root cause

   • src/services/cache/cache-key.ts:64–71 distinguishes jobs when saving, but buildRestoreKeys at lines 36–43 has no run/job specificity.
   • src/services/cache/restore.ts:270–282 restores using a shared primary prefix plus broad fallbacks.
   • The logical session key remains stable across attempts, but its session is missing from the selected database; src/harness/phases/session-prep.ts:101–125 consequently finds no continuation.

   The existing re-run test checks identifier stability without restoring competing snapshots, so it misses this failure.

   Recommended next steps

   1. Adopt save keys shaped as {primary}-{runId}-{invocationIdentity}.{attempt}, including the matrix-leg identity, and prefer {primary}-{runId}-{invocationIdentity}. on restore.
   2. Make that preference the restore primary key, or perform a separate first lookup. @actions/cache prefix-matches its primary key before trying restore keys. Simply prepending a job-specific fallback behind today’s broad primary key still restores the sibling. A local selection control verified this ordering and the . delimiter’s protection against fro-bot matching fro-bot-remediate.
   3. Retain today’s broad primary/ref/repo fallbacks for new runs and old-format entries, and verify entity-bound session behavior remains intact. This is bounded re-run recovery; merging parallel histories remains Make concurrent Action session publication safe so Action runs need no repository lock #1712.
   4. Add regression coverage for earlier-job re-runs under both triggers, multiple attempts, prefix-related job names, matrix siblings, and legacy fallback. Exercise real runCleanup and runPost with matrix context, asserting the actual cache keys and artifact names agree at the external boundaries.

   Temporary reproduction tests were removed after investigation; the working tree is unchanged.

   ---

   Run Summary

   Field	Value
   Event	issues
   Repository	fro-bot/agent
   Run ID	38088981712
   Cache	hit
   Session	ses_ed83630a6ffeseXBcwz3jYiRVf
3. fro-bot

   removed

   agent: working

   on Oct 10, 2026