eric/distributor
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 7 Wiki Activity

Update documentation to clarity bundle_id and idempotency_key usage and distinctions

Browse Source
This commit is contained in:
Eric Rakestraw
2026-06-07 20:45:29 -05:00
parent 25fbfc4677
commit f98e528c90
6 changed files with 27 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/integrations/http-upload.md
View File

@@ -71,7 +71,7 @@ Retryable idempotency conflicts include:
{"error":"upload idempotency key is already being processed","retryable":true}
```
When `Idempotency-Key` is omitted, upload admission preserves the raw HTTP behavior: every valid accepted upload receives its own run id. When a key is supplied, the server records the accepted run after archive staging and source bundle validation succeed. Reusing the same key for the same authenticated pipeline and the same normalized source manifest returns the original `202 Accepted` response and does not enqueue another run. Reusing the same key for a different normalized source manifest returns `409 Conflict`.
When `Idempotency-Key` is omitted, upload admission preserves the raw HTTP behavior: every valid accepted upload receives its own run id. When a key is supplied, the server records the accepted run after archive staging and source bundle validation succeed. Reusing the same key for the same authenticated pipeline and the same normalized source manifest returns the original `202 Accepted` response and does not enqueue another run. Reusing the same key for a different normalized source manifest returns `409 Conflict`. Producers should use a fresh key for each distinct producer run and reuse a key only for retries of that same run.
### `GET /runs/<run-id>`

2
docs/integrations/source-bundle.md
View File

@@ -27,7 +27,7 @@ Current schema version: `1`.
Required manifest fields:
- `schema_version`: must be `1`.
- `id`: non-empty bundle identifier.
- `id`: non-empty bundle identifier. For replacement workflows, keep this stable for the logical source that should update the same managed destination artifact.
- `digest`: lowercase `sha256:<64 hex>` digest of the ordered `files` list.
- `created`: RFC3339 timestamp.
- `files`: non-empty ordered list of file records.