Flaky e2e integration CI: server-side settle/submit races (VTXO_ALREADY_SPENT / INVALID_ARK_PSBT duplicated tx / INVALID_INTENT_PROOF)

[tiero]

Summary

The sdk package's e2e integration matrix (Integration (sdk / *) CI jobs, driven by scripts/regtest.sh against the live regtest arkd) intermittently fails with server-side rejection errors that look like a race between back-to-back tests sharing one regtest stack, not a client-side bug. Two independent occurrences observed within the same PR (#827), on two different commits, in two different test files, both in the same error family.

Observed failures

1. test/e2e/arkadeCash.test.ts > ArkadeCash > should claim each arkadeCash independently

• Job: Integration (sdk / arkade-assets), commit 4c48240e9466732b7b479f0722bbd6bdb68f09f8, 2026-09-03 ~14:50 UTC
• Error:

  ArkadeCashCreateError: Failed to create ArkadeCash: send failed after the note may have been submitted.
  Caused by: VTXO_ALREADY_SPENT: VTXO_ALREADY_SPENT (6): 333cabae45f44974455a568b2eb374d2b6b27d5d0327c9828286066cda5cd08b:0 already spent
  

• Stack: Wallet.createCash → Wallet._submitOffchainSpend → RestArkProvider.submitTx → handleError → maybeArkError
• Re-ran (via GitHub UI, not by this session — no permission) at ~15:12–15:18 UTC on the same commit and passed clean: Integration (sdk / arkade-assets) re-run — nothing in the tree changed between attempts.

2. test/e2e/unilateralExitDeepChain.test.ts > unilateral exit — deep chain ordering > prepare() emits a deep offchain send chain in physical-input topological order

• Job: Integration (sdk / exit-providers-rotation), commit 9982e05ecb557344c8e7806376ca52291475bbe0, 2026-09-03 ~15:54 UTC
• Error:

  INVALID_ARK_PSBT: INVALID_ARK_PSBT (1): duplicated offchain tx eaeef0853d33c85473cc1ac1bfddaa2a6006af9d0a70152064028f7a072b76b8
  

• Stack: Wallet._submitOffchainSpend → submitOffchainTx → RestArkProvider.submitTx → handleError → maybeArkError
• Immediately preceding this failure in the same job's log, the prior test in file order (test/e2e/digestMismatch.test.ts, which passed) logged its own settle-cleanup failure:

  Failed to delete intent after settle failure for inputs [573e326454acf43c705427011297ec786981fa87875d3f9e19785eb9c1c2da6b:0];
  intent may linger on server and cause 'duplicated input' on next settle
  INVALID_INTENT_PROOF: INVALID_INTENT_PROOF (23): no matching intents found for intent proof
  

  This reads as a lingering/leaked intent or in-flight settle state from one test bleeding into the timing of the next, inside the same suite run against one shared arkd.
• As of this writing this job is still red on 9982e05, unretried (no permission to trigger rerun_failed_jobs from this session — GitHub API returned 403).

Why this looks like flake, not a real regression

• Both failures are server-side rejections (VTXO_ALREADY_SPENT, INVALID_ARK_PSBT: duplicated offchain tx, INVALID_INTENT_PROOF) from a live regtest arkd, not assertion failures or client-side exceptions.
• Two different tests, two different error codes, two different commits — same PR, same shared regtest stack per job.
• PR Rename ts-sdk package to sdk #827 (the PR these were observed on) is a pure directory rename (packages/ts-sdk → packages/sdk) plus path/script/doc string updates; zero runtime logic changed. Full local typecheck, build, lint, and unit suite all pass clean on both commits.
• Occurrence 1 passed on an unmodified re-run of the identical commit, which rules out anything content-dependent.

Suspected root cause (untriaged beyond this)

Something in the e2e suite's settle/submit lifecycle — likely around cleanup after a failed or slow settle (deleteIntent, forfeit/commitment timing, or VTXO tree renewal racing a subsequent test's own settle round) — leaves state on the shared arkd that the next test's submit collides with under CI's tighter timing (2-core runner, see the REGTEST_PROFILES comment in packages/sdk/.env.regtest). The Failed to delete intent after settle failure ... may cause 'duplicated input' on next settle log line is the SDK's own code anticipating exactly this failure mode, which suggests it's a known-possible interaction, not a new one.

Suggested next steps

• Grep for the Failed to delete intent after settle failure log site (src/wallet/wallet.ts, _settleImpl) and check whether the cleanup-failure path leaves the wallet retrying/settling again before the server has fully released the prior intent/VTXO.
• Consider whether e2e tests that settle need a stronger post-settle barrier (wait for confirmed VTXO state, not just the settle response) before the suite moves on to the next test that spends from the same wallet/keys.
• If genuinely just CI timing under contention, consider whether REGTEST_PROFILES/runner sizing needs another look, or whether flaky-prone tests should get a bounded retry at the suite level.

Environment

• CI: GitHub Actions, ubuntu-latest, 2-core runner
• Workflow: .github/workflows/ci.yml, Integration (sdk / *) matrix
• Regtest stack: arkade-regtest submodule, driven by scripts/regtest.sh sdk cycle
• Both failures on branch claude/rename-ts-sdk-to-sdk-luwki0 / PR Rename ts-sdk package to sdk #827, base master @ c6190783

[arkana-ai-bot]

Debug analysis

Three distinct error codes appear in this report, but they share one root cause: leaked intent state from a failed or slow settle in one test bleeds into the next test's submit, on a shared arkd instance.

---

Code path for VTXO_ALREADY_SPENT (test 1: arkadeCash.test.ts)

Wallet.createCash → _submitOffchainSpend → buildAndSubmitOffchainTx → submitOffchainTx → RestArkProvider.submitTx → handleError → maybeArkError

_submitOffchainSpend (wallet.ts:5761) has no VTXO_ALREADY_SPENT retry branch — it propagates the error as ArkadeCashCreateError. That is correct for production (an atomic cash-create should not silently retry a stale input). But in CI, if a prior test's settle consumed the same VTXO and the server's authoritative state advanced while the local cache still shows it spendable, the submit is dead on arrival. The vtxo-manager.ts periodic-settle path has a maybeRefreshAfterVtxoSpent throttle (line 2806) that would catch this on the next cycle — but the createCash path doesn't go through that machinery.

---

Code path for INVALID_ARK_PSBT: duplicated offchain tx (test 2: unilateralExitDeepChain.test.ts)

The immediately preceding log from digestMismatch.test.ts is key:

Failed to delete intent after settle failure for inputs [...];
intent may linger on server and cause 'duplicated input' on next settle
INVALID_INTENT_PROOF: INVALID_INTENT_PROOF (23): no matching intents found for intent proof

This is the SDK's own warning, emitted at wallet.ts:4273-4277 in the pre-commit failure branch of _settleImpl. The deleteIntent call is fire-and-forget with .catch(console.warn) — so when it fails (here: the server says no matching intents found, meaning the intent was already finalized or expired server-side), the warning is logged and execution continues. The settle's inputs are still considered registered by the server in some in-flight state, and when the next test calls _settleImpl with overlapping inputs, the server sees a duplicated transaction and responds with INVALID_ARK_PSBT.

The safeRegisterIntent method (wallet.ts:4746) does handle the duplicated input variant of this error — it signs a deleteIntent for the caller's own inputs and retries — but it catches error.code === 0 && error.message.includes("duplicated input") (wallet.ts:4756-4757). The INVALID_ARK_PSBT: duplicated offchain tx error thrown in this failure has a different code (1, not 0) and a different message, so it bypasses that recovery branch.

---

Why it passes on re-run

Between the failed run and the re-run, the shared arkd completes or expires the in-flight intent. The next run sees a clean server state, so neither the stale VTXO nor the duplicated transaction error surfaces.

---

Suggested fix approaches

1. Test isolation (primary): each test file that settles should get its own funded wallet/boarding UTXO, not share VTXO state with adjacent tests that run in the same suite against the shared arkd. The Failed to delete intent ... intent may linger log in the SDK is explicitly anticipating this cross-test contamination.

2. Post-settle barrier in tests: after any test that calls settle (or any operation that registers an intent), await confirmation that the server has fully processed the intent before the test runner continues. A short poll on the indexer for the settled VTXO state would prevent bleed-through.

3. safeRegisterIntent coverage: consider whether the INVALID_ARK_PSBT (code 1) duplicated offchain tx variant should be caught alongside the code-0 duplicated input case — the recovery is the same (delete the stale intent and retry). Currently wallet.ts:4756-4757 only handles one shape of the error.

4. deleteIntent retry on failure: the .catch(console.warn) at wallet.ts:4273 is the known leak point. A single bounded retry on INVALID_INTENT_PROOF (which may just mean the server processed the intent concurrently) would reduce the lingering-intent window.

The PR under test (#827) is a pure rename — it cannot introduce this race; the flake is pre-existing, just newly visible under 2-core CI timing.