randomparity / randomparity/kdive
Implement durable external-build finalization if measurements require it
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- Avg merge
- 1h 26m
- Merged PRs (30d)
- 311
Description
## Problem
External-build finalization currently has no durable completion handle after a transport interruption. Whether this requires an asynchronous job must be decided by the measurement and completion-contract work split from #2314.
Part of #2314.
## Evidence
- `src/kdive/services/runs/complete_build.py:146-169` owns validation and publication synchronously.
- `src/kdive/domain/operations/jobs.py:17-58` retains `build` only as a retired persisted kind.
- `src/kdive/jobs/queue.py:96-123` rejects enqueueing retired job kinds.
- `src/kdive/jobs/payloads.py:237-265` contains historical build payload semantics that do not represent external-build finalization.
- `src/kdive/db/schema/0138_external_boot_recovery_quarantine.sql:1-11` constrains the current persisted job-kind vocabulary.
- `src/kdive/services/runs/complete_build.py:553-586` defines upload-window and object-identity fencing that any durable owner must preserve.
## Expected
If the accepted completion-contract decision requires asynchronous finalization, the existing `runs.complete_build` entry point returns durable progress that survives disconnects and can be observed through `jobs.*`. Exactly one owner validates and publishes an upload generation, and retries, cancellation, expiration, reaping, and remint races have defined outcomes.
If measurements establish that supported finalization reliably remains synchronous, close this issue without implementation and record that evidence.
## Proposed approach
After the completion-contract decision, either close this issue with the synchronous proof or implement a dedicated active job kind and payload, schema migration, enqueue/deduplication behavior, worker handler, terminal result, MCP response and wrapper guidance, cancellation semantics, upload-window fencing, concurrency tests, and a live transport proof.
Do not reactivate historical `JobKind.BUILD`; its payload and lifecycle describe the removed server-build lane.
Contributor guide
Research direction
Start with the measurement and completion-contract decision from #2314, then read src/kdive/services/runs/complete_build.py, src/kdive/domain/operations/jobs.py, src/kdive/jobs/queue.py, src/kdive/jobs/payloads.py, and the 0138 schema migration. Done means either recording evidence for synchronous finalization and closing the issue, or implementing and testing the dedicated durable job path while preserving the stated fencing and lifecycle outcomes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, sql
- Domain
- api, backend, databases, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100