Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity

feat: merge durable Workdir updates from develop

Browse Source 
# Conflicts:
#	docs/README.md
#	docs/design/durable-operations.md
#	web/workspace/deno.json
This commit is contained in:
Hare
2026-09-03 02:47:50 +09:00
parent bcd4848458 538da1f2b2
commit a595af133c
43 changed files with 6467 additions and 524 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/README.md
+1 -1
View File
@@ -7,7 +7,7 @@ It is not a dumping ground for external research, old plans, API inventories, or
## Reading order
1. [`design/overview.md`](design/overview.md) — the system map.
2. [`design/durable-operations.md`](design/durable-operations.md) — cross-domain operation identity, checkpoints, retries, child operations, and disposition.
2. [`design/durable-operations.md`](design/durable-operations.md) — cross-domain operation identity, checkpoints, retries, child operations, and disposition, including durable Workdir removal.
3. [`design/context-history.md`](design/context-history.md) — the highest-risk invariant: inputs that affect the model must be committed to history before they enter context.
4. [`design/worker-session-state.md`](design/worker-session-state.md) — Worker identity, replayable session logs, current metadata, and live process hints.
5. [`design/session-observation.md`](design/session-observation.md) — common session captures, `SessionEntryRef`, Memory evidence, and host-authorized Worker observation.
docs/design/durable-operations.md
+47
View File
@@ -254,6 +254,53 @@ compensation has its own external side effects or retry lifecycle, give it a
stable child operation identity rather than expanding the parent into a list of
cleanup stages.
## Workdir removal application
Workdir removal is one durable side-effect operation in the Workspace Server
DB. It binds the Workspace, Workdir, owning Runtime,
Repository/materialization identity, source actor, stable intent fingerprint,
lifecycle, retry metadata, and bounded result. Runtime URL, provider handle,
host path, credentials, and caller-selected Runtime are not operation inputs.
A durable one-pending-operation constraint plus an atomic attempt claim prevents
concurrent callers from entering the provider side effect for the same Workdir;
the in-process resource lock is an additional serialization layer, not the sole
authority. Each active attempt persists the Server process ID and process-start
marker. Recovery reclaims only an owner proven missing or replaced; a live or
unobservable owner is never stolen. The reclaim transaction compare-and-set
checks the exact proved owner snapshot and attempt count so stale orphan proof
cannot overwrite a newer live claim.
Each attempt:
1. resolves or revalidates the persisted same-Workspace Workdir, Runtime,
Repository, and materialization identity;
2. checks current attachments, attachment reservations, current assignment
occupancy, retention/cleanup holds, and pending materialization authority; a
failed Workdir-create retry must atomically return to `pending` before
provider work and is rejected while removal is pending;
3. retains dirty, occupied, blocked, or otherwise unknown Workdirs without
detaching a Worker or forcing deletion;
4. observes the owning Runtime/provider and calls its existing Workdir cleanup
only for an eligible clean Workdir;
5. treats only successful provider cleanup or exact
`working_directory_not_found` as removal evidence;
6. deletes the Backend Workdir registry row and commits the operation's
`completed`/`removed` result in one SQLite transaction.
A provider error leaves the registry intact and records a bounded
`attention_required` result with explicit retryability. Startup recovery lists
`pending` and retryable `failed` operations, then executes this same path after
rereading live authority. `WorkdirDelete`, Workspace REST removal, Runtime
cleanup execution, and recovery must not maintain separate inline
provider-delete paths.
The public request contains only `working_directory_id` plus a bounded reason.
The public result contains only the Workdir ID,
`removed | retained | attention_required`, retryability, and an optional bounded
failure category. Internal operation identifiers, checkpoints, provider paths,
and credentials are not public DTO fields.
## Diagnostics and audit
Persist bounded error categories and identifiers needed to investigate or retry.