Verdict

Flaky test, not caused by PR #7905. dynamodb_conditional_put_skips_existing_row failed in the Adapter Tests job of a merge-queue run for #7905, a PR that only touches checkpoint/GC code (crates/connectors/src/controller.rs, crates/dbsp/src/circuit/checkpointer.rs, crates/dbsp/src/circuit/dbsp_handle.rs, crates/connectors/src/engine.rs, crates/static-connectors/src/engine.rs). git diff against main shows zero changes under crates/connectors/src/integrated/dynamodb/.

Evidence

• Job: Adapter Tests / Test Adapters (amd64)
• Failure (log line ~2700):

  thread 'main' panicked at crates/connectors/src/integrated/dynamodb/test.rs:1477:5:
  assertion `left == right` failed
    left: 1
   right: 2
  

  Line 1477 is assert_eq!(rows.len(), 2); in dynamodb_conditional_put_skips_existing_row: after a conditional-put transaction that re-emits an existing key (expected to be skipped) alongside one new key, the table ends up with only 1 row instead of 2 — the new row didn't land, or the whole transaction was dropped.
• The test runs against DynamoDbLocal (an emulator container); this shape of failure (fewer rows than expected after a single batch) is consistent with a transaction/container timing race rather than a logic bug, and no other test in the same suite run failed in this area.

Next step

• Re-running the merge queue is likely to pass; this looks like an isolated flake.
• Worth checking whether DynamoDbLocal's conditional-transaction handling has any known timing sensitivity, and whether the test should retry the scan or add a settle delay.