Repository navigation
a run's own scratch note no longer fails the delivery gate - #1096
Conversation
santoshkumarradha
changed the title
|
Pre-merge run on the exact head e6c0b6a: Spark job 20260917-080738-000544, go build ./... ok, go vet ok, go test -count=1 ./cmd/codeaf/... ok. Earlier job 20260917-080149-000543 on 9ba0faa (same code, before the change note) also green. Live check: a scratch do run finished with exit 0 and left no note in the tree. |
|
Hi @AbirAbbas, please review as high priority. |
leafOutputHint invited a job root to write its overflow document at a workspace-relative name (exec.SuggestPathFor's task-2-x1-toolchain-checks.md shape), so a run working in a person's directory left that note untracked at the root of their working tree. The delivery gate holds the run's record — the artifact registry, joined by jobArtifacts, plus the delivered tree — against the request, read the note as part of what was handed over, and refused the delivery; the run then ended incomplete over complete work. There is no separate mechanical clean-tree check to exempt, so the fix is the writer's: where the workspace belongs to the person, the root's file invitation points at the run's scratch beside its recorders and job logs, and the message keeps carrying the deliverable.
TestARootLeafInAPersonsDirectoryPutsItsNotesInScratch baselined the tree after the note was already written, so its landing read could never have observed anything: the record stayed empty because of the ordering, not because of the address. The baseline now happens first, in the executor's own order, and a hint that ever points into the tree again fails on the observation, not only on the spelling. And the other half of the law is pinned down: a file that turns up in the person's tree while the leaf runs — even at a name wearing the run's own task-<n>-<slug>.md shape — is still observed and still lands in the record the delivery gate is held to. Only the run's own note moved; nothing else about what the tree says was loosened. Co-Authored-By: codeaf <[email protected]>
e6c0b6a to
3189c40
Compare
|
Retargeted to |
|
Correction: the Spark job for this head is |
|
Spark |
codeaf doworks in the person's own directory, so its job root's workspace isOwnedByPerson.leafOutputHintoffered that root the overflow-documentaddress
exec.SuggestPathFor(node.ID, title)— a workspace-relativetask-<n>-<slug>.md— while every intermediate leaf was already pointed at therun's scratch. A root that took the offer left an untracked file at the root of
the person's tree.
Workspace.RecordChangesobserved it,Workspace.Artifactsfiled it,
jobArtifactsjoined it into the record the delivery gate is held to,and the gate read a file the request never named as part of what was handed
over and refused the delivery; the run then ended incomplete over work that was
complete and committed.
There is no separate mechanical clean-tree check to exempt, so the fix is the
writer's, not the reader's: where the workspace belongs to the person, the job
root's file invitation is resolved through
Workspace.ScratchPath, the sameaddress an intermediate leaf gets, and the withdrawal for a directory already
standing at that name is measured at the scratch spelling. The final message
still carries the deliverable.
Nothing is excluded by name.
Workspace.recorddrops any path outside the root,so a note written at the offered scratch address is never in the record; a file
that turns up in the person's tree while the leaf runs is still observed and
still lands in that record, whatever it is called.
Tests beside the touched package cover the three halves: a personal root is
offered a path under the run's scratch and the tree it was judged in is left
empty; a file appearing in the person's tree at a name wearing the same shape
still joins the record; a directory at the offered scratch path still withdraws
the invitation.
🤖 Generated with Claude Code