Building a Nostr client (NOSTRAS, nostras.app) on @secondts/bark (web/WASM target, currently 0.21.0), Signet network.
Started an emergency exit on a real funded VTXO (175,035 sats) via startExitForEntireWallet(). State correctly moved to start. Called progressExits({}) — VTXO correctly advanced to processing, and I can see real activity in the network tab (fee-estimates, block/height queries, several successful txs/address-history lookups against esplora.signet.2nd.dev).
But two identical 404s also appear, both directly querying the VTXO’s own id against esplora:
15fd03855a10172d6a7c86dd4964568e8ea5adede55c1e7c4aeb7d63ff581048
Confirmed independently with curl: /tx//status returns {“confirmed”:false} (200 OK), but /tx/ (the full transaction) returns a genuine “Transaction not found” (404). So the transaction the exit is waiting on for this stage doesn’t actually exist on the network yet.
Waited 15 minutes and clicked “progress” again — exact same 404 recurs, so this doesn’t look like propagation delay.
Saw the June changelog entries on “Resilient Exit Progress Tracking” and the exit-claim v2/v3 fix a few days later — wondering if this is related, or a known issue. Is there a way to force a re-broadcast of whatever stage this is stuck on, or additional diagnostics I can pull client-side to help narrow it down? Happy to share more (full request logs, wallet config) if useful.
Hey Erik — thanks for the quick response! Here’s the real output (the includeTransaction field in your snippet needed to be includeTransactions — plural — and the vtxoId needs the :0 outpoint suffix, not just the bare txid, in case that trips anyone else up):
So it looks like it made it through verify-inputs and has been sitting on awaiting-cpfp-broadcast ever since — no further progress in the history. Let me know if there’s anything else useful I can pull (I’ve got the wallet handle available in-browser right now, nothing discloded here since we are at Signet).
I am currently checking what happened. While I am at it, do you have enough coins on your onchain wallet to pay for the onchain fees used in the CPFP broadcast? And, is the wallet daemon running? `wallet.runDaemon()`
Hi luca, thanks for looking into it. To answer directly: the wallet daemon is not running, by design — our integration opens the wallet with runDaemon: false and only calls progressExits() when the user manually clicks a ‘progress exit’ button in our UI, there’s no background/continuous driving of the exit at all. If CPFP rebroadcast needs the daemon actively running to make progress, that’s very likely what we hit. On the on-chain balance — checking now, will confirm shortly.
On-chain balance — confirmed, plenty of sats there to cover fees.
You’re right — confirmed by reading our own code: progressExits() was called with no sync before it, so the on-chain view could genuinely have been stale by the time a user clicks ‘progress exit,’ since exits progress over real block time and the on-chain wallet was only ever synced once at wallet-open. Fixed on our side (calling onchainWallet().sync() right before progressExits() now) and shipped. Thanks for the precise pointer — this was likely the actual cause.
Tested the fix against the same VTXO from the original report. The sync fix is real and shipped, but it didn’t change the outcome here — confirmed directly (not just in our UI): GET /tx/15fd03855a10172d6a7c86dd4964568e8ea5adede55c1e7c4aeb7d63ff581048 still returns a genuine 404 ‘Transaction not found’ on esplora.signet.2nd.dev (esplora itself is healthy, current tip height 320681). So this specific txid appears to have never actually landed, or something replaced it — not just a stale local view on our side. Full txid above if useful, happy to share more logs/state if it helps.
My theory right now then is that there is a mempool conflict or the inputs were already spent.
After you press the progress exits button, can you check the Network tab, filter per package and tell me if there is an POST .../txs/package? If yes, what is the response body?
Confirmed directly — filtered Network on package, clicked Progress exit, zero matches. Other traffic did fire in the same window (that’ll be the on-chain sync we added), so it’s not that nothing ran at all — progressExits() itself apparently just doesn’t attempt a broadcast this time.
On our side, progressExits() is a single opaque call into the Bark WASM SDK — we don’t construct or send that POST ourselves, so I can’t tell you why it decided not to broadcast, only that it didn’t. Combined with the original txid still 404ing on esplora directly, this reads less like a mempool conflict and more like the SDK’s internal exit state considers this VTXO already resolved/in-flight even though nothing corresponding ever landed on-chain — which would line up with your “inputs already spent” theory, just as stale SDK state rather than an actual chain-level conflict.
If it’d help narrow it down faster than relaying logs back and forth, NOSTRAS’s Ark integration is live and public at app.nostras.app (Signet, same Bark web SDK) — happy to have you reproduce it directly with your own test wallet.
I will try to reproduce it and debug it. progressExits should have called the broadcast, so that is why I asked you to check that. This will help us to trace down the code calls and what it is hitting.
