feat(github): resume the prior session when github run retries#32584
Open
NathanDrake2406 wants to merge 2 commits into
Open
feat(github): resume the prior session when github run retries#32584NathanDrake2406 wants to merge 2 commits into
NathanDrake2406 wants to merge 2 commits into
Conversation
github-actions
Bot
added
contributor
needs:compliance
Contributor
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
opencode github run always calls Session.create(), so a retry that re-spawns the command on the same runner starts a fresh session: the agent re-clones the repo, re-reads the PR/issue, and re-prompts the model from zero even though the prior attempt's session is still in the local DB. Every retry pays full setup cost again. github run never wired in the session resume that opencode run already has via --continue/--session. The fix keys the session on GITHUB_RUN_ID (stable across re-runs; only GITHUB_RUN_ATTEMPT increments) by stamping it into session metadata at creation, then on start reuses the session for that run id when one exists instead of creating. When continuing it sends a short nudge rather than re-injecting the full prompt, which is where the tokens are saved. The user prompt is persisted before the model call, so a transient mid-call failure leaves it in history and the nudge has context. If the prior attempt died during setup before any message was stored, it falls back to the full prompt so the resumed session still receives the task. Scope: same-runner retries only, where the session DB survives. A GitHub UI re-run lands on a fresh runner with an empty DB and still starts fresh; persisting the data dir across runners is out of scope. The two decisions are pulled into pure functions (findResumableSession, shouldSendContinuation) keyed by a shared GITHUB_RUN_METADATA_KEY. The handler's resolution sequence is exercised against the real Session service and SQLite, plus pure branch tests for each decision. Fixes anomalyco#32583
NathanDrake2406
force-pushed
the
feat/github-run-resume-session
branch
from
e31b32f to
ab4266e
Compare
Query session metadata by GITHUB_RUN_ID instead of depending on bounded session listing, so same-runner retries find the workflow-run session directly. Keep continuation prompt/file selection in a tested helper and cover lookup past the list limit, duplicate/fork metadata, and resume prompt behavior.
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
1 participant
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.
Issue for this PR
Closes #32583
Type of change
What does this PR do?
opencode github runcallsSession.create()on every invocation, so a retry starts a new session. The agent redoes all the setup: re-clone, re-read the PR/issue, re-prompt the model. The prior attempt's session is still in the local DB, but nothing looks for it.This stamps
GITHUB_RUN_IDinto the session metadata at creation. That id stays the same across re-runs (onlyGITHUB_RUN_ATTEMPTchanges), so it works as a resume key. On start,github runlooks up the session for the current run id and resumes it if found, otherwise creates as before.On resume it sends a short "continue" message instead of re-sending the full prompt, which is where the tokens are saved. The user prompt is persisted before the model call, so a transient mid-call failure (the case a retry targets) leaves it in history and the nudge has context. If the prior attempt died during setup before any message was written, it falls back to the full prompt so the model still gets the task.
Scope: same-runner retries, where the session DB survives (for example a wrapper that re-runs the command after a transient failure). A GitHub UI "Re-run" starts on a fresh runner with an empty DB and still creates a new session. Persisting the data dir across runners is a separate change, called out in a code comment.
How did you verify your code works?
findResumableSessionand tested it against the real Session service and SQLite: match by run id, isolation across runs, no-match returnsundefined, and a fork (which copies metadata) resolves back to the original. Plus a pure tiebreak test.bun test test/cli/github-resume.test.tspasses (6). Existinggithub-action.test.tsandgithub-remote.test.tspass (33).bun run typecheckis clean.oxlintis clean on the changed files.github runflow (OIDC, octokit, git) has no automated coverage here; it needs a live GitHub Actions environment to exercise end to end.Screenshots / recordings
Not a UI change.
Checklist