Conversation
- workspace-router check advances the workflow_wait event cursor so the polling loop blocks on new events instead of racing run completion - repair reuse accepts checkpoint dependencies while the recomputed value hash matches the source run, and still invalidates on value changes - drop the unreachable second requestId lookup in start() - dist/main.mjs rebuilt from the changed engine (byte-reproducible build)
Author
|
Related design discussion for the repair-reuse machinery in this PR: #46 (tamper-evident reuse results). No action needed on this PR — the issue is a forward-looking proposal. |
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.
What changes
Three small correctness fixes for
plugins/hetaoBackend/mcode-dynamic-workflows(merged via #42), split out so each is reviewable on its own.Deterministic review-loop polling (
checks/workspace-router.check.mjs): the wait loop calledworkflow_waitwithoutafterSequence.waitEventsreturns immediately whenever any event exists after the cursor (src/tools.mjs), and withafter=0events always exist — so all 30 iterations burned in ~65 ms on a warm machine while the run needed ~66 ms. The outcome is decided by IPC latency: we reproduced both a failure and a pass on the same machine at the same commit. The loop now advancesstatus.nextSequence, so each call blocks up to 500 ms for a genuinely new event; the worst case stays bounded (30 × 500 ms).Checkpoint lineage in repair reuse (
src/engine.mjs): the candidate lineage check required every dependency to carryreusedFrom.runId === sourceRunId. Checkpoints recompute every run by design and never carryreusedFrom, so any agent step with a checkpoint independsOnsilently fell back to a fresh (billable) call even when the candidate was valid. Checkpoint dependencies now accept the recomputed step when its requestHash matches the source run's checkpoint; a changed checkpoint value still invalidates downstream reuse. A regression test covers both directions.Dead code (
src/engine.mjs): removed the secondbyRequest(requestId)lookup instart()— unreachable, since the first lookup returns for any existing request and nothing writes the store in between (no await point). For the record: we initially also flagged the trailing re-check inresume()as redundant — wrong; it is the TOCTOU guard after the fingerprintsawait, and the "simultaneous resumes launch only one replay" test caught our mistake before this PR was filed.dist/main.mjsis rebuilt from the changed engine; the build remains byte-reproducible.Verification
node --test checks/*.check.mjs: 73/73 (72 existing + 1 new checkpoint-lineage test)node --test test/package.test.mjs: passnpm run check(clean checkout, pluginnode_modulesremoved): greenNeed help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.