feat(sync,exec): okdev sync wait; split command-exit from delivery-failure exit semantics#159
Merged
Merged
Conversation
…y-failure semantics okdev sync wait [session] [--timeout 10m] blocks until every sync mapping has zero pending bytes in both directions, giving scripts the edit-run guarantee (vim f.py && okdev sync wait && okdev exec -- python f.py). It forces a rescan on both sides first so files written moments earlier are indexed immediately instead of after the FS-watcher delay, and fails fast with guidance when background sync is not running. Fanout exec failures are now layered: when every failing pod merely reported a non-zero command exit, the summary is COMMAND EXITED NON-ZERO and okdev exits with the remote status (single pod, preserving the documented verbatim-exit contract) or 1 (multi-pod). Any delivery failure (unreachable, timeout, container gone) keeps the FAILED framing and maps to new dedicated exit code 69 (sysexits EX_UNAVAILABLE) via the ErrExecInfraFailure sentinel, so scripts can tell "my command failed" from "okdev could not deliver the command" without parsing output. Covered by unit tests plus kind e2e scenarios (sync wait convergence guarantee, single-pod exit-status preservation, multi-pod non-zero framing). Docs and skill references updated. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
acmore
force-pushed
the
feat/sync-wait-and-exec-exit-semantics
branch
from
06a76fa to
e63940c
Compare
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.
What
Two scripting-reliability gaps in the edit-run loop, addressed together because both are about making okdev's exit behavior trustworthy for scripts and agents.
okdev sync wait(new subcommand)Blocks until every configured sync mapping has zero pending bytes in both directions, then returns:
--timeout(default 10m) with pending-byte progress while waiting; timeout error points atokdev status --details.Fanout exec exit semantics
Previously any pod failure — including the command itself exiting non-zero — produced the same
FAILED: ... N of M pods failedframing and exit 1, so scripts could not tell "my command failed" from "okdev could not deliver the command". Now:COMMAND EXITED NON-ZERO:exit 3→ 3)COMMAND EXITED NON-ZERO:FAILED:The single-pod case also fixes a docs/behavior mismatch: the command reference promised the remote status is "always preserved", but the fanout path flattened it to 1.
Testing
ErrExecInfraFailureand classifies to 69.sync wait→exec catproves the guarantee; single-podexit 3→ exit status 3 withCOMMAND EXITED NON-ZEROframing. pytorchjob — multi-podexit 3→ exit 1, noFAILED:header.gofmt,go vet,go test -race ./...all clean.Docs (
command-reference.md) and skill references updated.🤖 Generated with Claude Code