fix(harness): don't re-stamp model metadata on a sandbox continuation - #6165
Open
pedrofrxncx wants to merge 1 commit into
Open
fix(harness): don't re-stamp model metadata on a sandbox continuation#6165pedrofrxncx wants to merge 1 commit into
pedrofrxncx wants to merge 1 commit into
Conversation
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.
Follows #6151, which added
withModelMetadatato stampmetadata.models.thinkingonto the claude-code harness's firststartchunk (mirroring what Decopilot already does).Bug:
sandbox-dispatch-client.ts'sdispatchOncewraps every dispatch attempt — including sandbox-lost continuations — inwithModelMetadata, and each call gets a fresh generator whose internalstampedflag resets tofalse.dispatchWithContinuationalready drops a continuation'sstartchunk (documented: forwarding a second one would re-id the message), but it does NOT know about themessage-metadatachunkwithModelMetadatayields right afterstart— so a run that survives a sandbox-lost retry gets a second, redundantmessage-metadatachunk spliced into an already-open message. Harmless when the model id is unchanged, but it's dead weight on every continuation and a landmine if a retry ever picks a different model.Fix: pass
nullfor the model id on a continuation attempt (resume ? null : modelEnv.CLAUDE_CODE_MODEL) sowithModelMetadatano-ops, consistent withdispatchWithContinuationalready treating a continuation'sstartas a no-op.Verify:
bun test apps/api/src/harnesses/sandbox-dispatch-client.test.ts— added a regression test (a continuation does not re-stamp model metadata) composingdispatchWithContinuation+withModelMetadatathe same way the real dispatch path does, asserting exactly onemessage-metadatachunk survives a sandbox-lost retry. Also ranapps/api/src/harnesses/with-model-metadata.test.ts(unchanged, still green) andcd apps/api && bunx tsc --noEmit.Locally ran:
bun run fmt,bunx tsc --noEmit(apps/api), the two targeted test files,bunx oxlinton both changed files. Full CI covers the rest.Summary by cubic
Prevent duplicate model metadata on sandbox continuation retries. Previously, a continuation emitted a second
message-metadatachunk becausedispatchOncealways wrapped attempts inwithModelMetadata; downstream dropped the secondstartbut not the metadata. Now, continuation attempts passnullas the model id sowithModelMetadatano-ops, matching how the continuation’sstartis suppressed and avoiding mismatched model ids.sandbox-dispatch-client.ts, passresume ? null : modelEnv.CLAUDE_CODE_MODELintowithModelMetadata.message-metadatachunk.message-metadatasurvives a sandbox-lost retry.Written for commit 5d27e27. Summary will update on new commits.