ee782b7d6e
Checkpoint implementation at user-requested stop; document known failures and incomplete release qualification. Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: GPT-6 Codex <noreply@openai.com>
2.3 KiB
Known retained-version reconciliation
DocumentGenerationService.reconcile(requestId) resumes a request only when its generation record already contains an exact retained version, hash and length. The current user must be the initiating actor, hold generation/view permissions (or print for a reprint), and still access the source record. The method refuses ambient transactions.
The retained-output adapter's inspect method reauthorizes the exact immutable version and reports current availability. The Record Files bridge implements this through its public get service; a quarantined receipt is visible without granting byte access or printing. A missing, failed, mismatched or unknown result is refused. Existing adapters remain compatible because the default inspect delegates to their stricter authorize method.
Recovery never rerenders or reuploads. It restores the known durable receipt, durably records the appropriate retained/reprint audit outcome, and either completes the generated result, reports QUARANTINED, or submits the original print intent using the original operation ID. The print adapter must implement that ID's idempotency contract and recheck current destination/source/version rights. If a queue ID was already persisted, a different returned queue ID is rejected. Queue acceptance remains distinct from physical printing.
Earlier audit stage meanings do not acquire later queue IDs during retries. Only PRINT_QUEUED and GENERATION_INCOMPLETE carry the observed queue identifier. The audit ledger deduplicates unchanged stage meanings while preserving the original observation timestamp.
A request without a persisted retained version remains explicitly uncertain. Absence of a retained file row is not proof that no original was written: owner storage intents/reservations may still require recovery. Automatic unknown-intake reconciliation awaits a typed Record Files intake-status/journal facade. No current API silently restarts such an operation.
This service method is an explicit recovery operation, not a background scheduler. Durable batch-item cursors, bounded leasing/claiming, restart recovery and per-record progress remain separate work. Current synchronous generateBatch pins a batch revision and records per-call outcomes but does not claim a durable worker queue.