Skip to main content
← Back to list
01Issue
BugOpenSwamp CLIPublic
AssigneesNone

Relationships

#1747 Concurrent pushes to one namespace fail with HTTP 409 ConditionalRequestConflict — the conditional PUT is never retried

Opened by psftw · 8/20/2026

On 20260817.010424.0-sha.21133ea1, a serve-side workflow with two sibling steps that complete within the same second fails one of them with:

@swamp/s3-datastore push failed (code=ConditionalRequestConflict): S3
putObjectConditional failed HTTP 409 ConditionalRequestConflict — The
conditional request cannot succeed due to a conflicting operation
against this resource.

Environment: @swamp/s3-datastore on OVH S3 ([HOST-1], region us-east-va), one namespace; the workflow runs serve-side, so every step completion pushes from the same process.

Mechanism: each step completion triggers its own datastore push, and both pushes rewrite shared namespace files (observed on .catalog-export.json). The writes go out as conditional PUTs; the loser of the race gets HTTP 409, the datastore has no retry for it, and the conflict surfaces as a push failure that fails an otherwise successful step.

Evidence: the journal shows two "Preparing push" lines inside the same second immediately before each failure. The "failed" push's objects verifiably land — correct content, Last-Modified at the failure second, index shards and _root.json updated. Direct S3 probes with the same bucket and credentials are clean: 25/25 PUT→HEAD→GET loops immediately consistent, unconditional PUT and DELETE fine. swamp run doctor clean. Reproduced 4/4 runs on the same workflow; earlier runs passed on luckier step timing.

Impact: any workflow whose sibling steps complete close together flaps — a step reports failure and downstream asserts never run, while the pushed data is intact in the bucket. A false negative on the run, not data loss.

Suggested fix: retry a conditional PUT on 409/ConditionalRequestConflict with a re-read of the current object and backoff, or serialize pushes per namespace inside the serve process so concurrent step completions queue instead of racing.

Workaround in use: serializing the formerly-sibling steps in the workflow DAG. That removes the deterministic pair but cannot close the race for steps on independent DAG roots, so intermittent flaps remain possible.

Upstream repository: https://github.com/systeminit/swamp-extensions

Environment

  • Extension: @swamp/s3-datastore@2026.08.12.1
  • swamp: 20260820.072114.0-sha.05d20b6a
  • OS: linux (x86_64)
  • Deno: 2.8.3
  • Shell: /bin/bash
02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED

Open

8/20/2026, 2:15:31 PM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.