Tighten failure and manifest contracts
This commit is contained in:
parent
5fdb339fe5
commit
a44b687897
1 changed files with 47 additions and 8 deletions
|
|
@ -22,8 +22,9 @@ deletion and cancellation semantics still use this request identity.
|
|||
|
||||
Internal claim uses job ID plus `operation_id` because no attempt exists yet.
|
||||
Renew, progress, and outcome use attempt ID, fencing token, worker incarnation,
|
||||
and `operation_id`. A replay has the original effect; a different, stale, or
|
||||
non-authoritative tuple returns `precondition_failed` without mutation.
|
||||
and `operation_id`. Each operation identity retains a request fingerprint. An
|
||||
exact replay has the original effect; a changed worker, fence, payload, stale,
|
||||
or non-authoritative tuple returns `precondition_failed` without mutation.
|
||||
|
||||
## Authorization and errors
|
||||
|
||||
|
|
@ -55,6 +56,11 @@ unauthorized, absent, and never-committed results are not exposed. The hard
|
|||
delete endpoint returns the durable deletion resource established by the
|
||||
architecture.
|
||||
|
||||
Worker failure outcomes accept only attempt-reportable runtime classes and do
|
||||
not accept a caller-supplied retryable flag. The service derives the durable
|
||||
disposition from the class mapping in the architecture. Validation,
|
||||
cancellation, and lost-attempt projection use their dedicated boundaries.
|
||||
|
||||
## WebSocket replay
|
||||
|
||||
An HTTP job or list snapshot carries `event_cursor` at its consistency
|
||||
|
|
|
|||
Loading…
Reference in a new issue