The Evelyn IOU burner currently sets a process-long swapsSuspended flag when a Jupiter transaction returns TIMED_OUT. Later hourly iterations never check the known transaction signature again, even if the transaction has since succeeded or failed. Recovery requires a complete Hub restart.
Replace this permanent timeout suspension with pending-swap reconciliation: retain the original signature, check its on-chain status in later scheduled iterations, and resume normal input selection once the previous operation has a definitive outcome. Do not confuse checking the same transaction again with submitting the same economic operation again.
This follows the confirmation distinction introduced in #68 and deliberately changes the burner policy from #72. It is separate from #90's token-denominated maxima and the proposed minimum-amount change.
Pending swap and later iterations
On JupiterTransactionOutcomeException with TIMED_OUT, retain the original non-blank transaction signature and the context needed to identify the input and attempted amount. Do not turn it into an untracked process-long suspension.
Preserve the existing pending-burn priority. Whenever a pending swap is reached in a later scheduled iteration, perform a bounded, read-only status check for that exact signature at CONFIRMED or stronger. Reuse the existing Solana/Jupiter confirmation infrastructure and RPC pacing; never call swap() merely to check an earlier operation.
If the transaction has succeeded, clear pending-swap state. If it has definitively failed on-chain, log its signature, slot and complete failure details, then clear pending-swap state. After either definitive result, normal selection may resume using newly read wallet balances, with at most one new swap attempt in the current iteration.
If the signature remains unresolved, confirmation times out again, or the lookup fails through I/O, retain the same pending state. Do not perform a new swap. Try that same status check again in the next scheduled iteration. Continue evaluating existing EVE for burning under the existing rules.
Interruption must propagate normally and preserve pending state; add no immediate retry loop or overlapping worker.
Dropped transactions and expiration
An absent signature or another timeout is not proof of failure. Do not clear pending state solely because a transaction is not found, because one hour elapsed, or because its blockhash is no longer valid.
The implementation must also permit recovery from a transaction that was genuinely dropped and can no longer land. Preserve the original transaction's validity metadata and add only the small read-only lookup support needed to establish expiration plus reliable absence from chain history. A lower-commitment observed transaction remains pending until its outcome is resolved. Only a demonstrated non-executed, expired transaction may be cleared as expired, after which balances are reloaded before any new swap. If evidence is unavailable or inconsistent, keep it unresolved and log what is missing.
Current JupiterTransactionOutcomeException exposes the signature, commitment and outcome but not expiry metadata, and current SolanaTransactionOutcome has no expiry result. Add only the structured context/status lookup needed for this burner recovery; do not infer status by parsing exception strings or implement a general reliable-submission framework.
Preserve a known signature in structured form when communication fails during confirmation, so that this case can use the same pending-swap reconciliation instead of losing the identity in an IOException message. Preserve the underlying cause.
Distinguish errors known to occur before submission from genuinely uncertain post-submission errors. A failed order request or other proven pre-submission error must not cause a process-long suspension; a later scheduled iteration may make a fresh attempt. Do not automatically resume after an ambiguous post-submission error without a trustworthy signature: preserve safe manual handling and clearly identify that limitation.
Improve the relevant logs to show canonical input symbol/UUID, attempted amount, original signature when known, confirmation/reconciliation status, relevant safe cause details, and the next action (check next iteration, resume after resolution, or manual investigation). Do not log credentials, signer responses, or raw signed/unsigned transaction payloads. Do not report TIMED_OUT as a definitive failure.
Verification and scope
Verify offline that an initial timeout is followed by checks of the same signature, success/failure/established expiry permit resumed selection, unresolved/absent-without-expiry/I/O outcomes retain pending state without new swaps, balances are reloaded after resolution, and existing EVE can still be burned while swap outcome remains unresolved. Verify pre-submission errors remain retryable in a later iteration and known-signature confirmation errors retain their structured identity. Verify unknown outcomes cause no automatic resubmission, and preserve normal interruption and one-swap-per-iteration behavior.
Update the affected OpenSpec requirements, JavaDoc and operating documentation through the normal workflow. Compile relevant sources, run strict validation and whitespace checks. Use controlled dependencies; do not perform live financial transactions. No permanent automated tests are requested by this issue.
Keep state process-local, following the current burner model, and document the restart limitation. No persistent transaction journal, rebroadcasting, automatic re-signing of an unresolved operation, new provider routing, direct Raydium swaps, minimum-buy configuration, Ticker changes or unrelated burn/lifecycle refactoring.
Related work: #68, #72, #83 and #90. This issue records implementation scope; implementation and deployment are separate tasks.
## Problem and outcome
The Evelyn IOU burner currently sets a process-long `swapsSuspended` flag when a Jupiter transaction returns `TIMED_OUT`. Later hourly iterations never check the known transaction signature again, even if the transaction has since succeeded or failed. Recovery requires a complete Hub restart.
Replace this permanent timeout suspension with pending-swap reconciliation: retain the original signature, check its on-chain status in later scheduled iterations, and resume normal input selection once the previous operation has a definitive outcome. Do not confuse checking the same transaction again with submitting the same economic operation again.
This follows the confirmation distinction introduced in #68 and deliberately changes the burner policy from #72. It is separate from #90's token-denominated maxima and the proposed minimum-amount change.
## Pending swap and later iterations
- On `JupiterTransactionOutcomeException` with `TIMED_OUT`, retain the original non-blank transaction signature and the context needed to identify the input and attempted amount. Do not turn it into an untracked process-long suspension.
- Preserve the existing pending-burn priority. Whenever a pending swap is reached in a later scheduled iteration, perform a bounded, read-only status check for that exact signature at `CONFIRMED` or stronger. Reuse the existing Solana/Jupiter confirmation infrastructure and RPC pacing; never call `swap()` merely to check an earlier operation.
- If the transaction has succeeded, clear pending-swap state. If it has definitively failed on-chain, log its signature, slot and complete failure details, then clear pending-swap state. After either definitive result, normal selection may resume using newly read wallet balances, with at most one new swap attempt in the current iteration.
- If the signature remains unresolved, confirmation times out again, or the lookup fails through I/O, retain the same pending state. Do not perform a new swap. Try that same status check again in the next scheduled iteration. Continue evaluating existing EVE for burning under the existing rules.
- Interruption must propagate normally and preserve pending state; add no immediate retry loop or overlapping worker.
## Dropped transactions and expiration
An absent signature or another timeout is not proof of failure. Do not clear pending state solely because a transaction is not found, because one hour elapsed, or because its blockhash is no longer valid.
The implementation must also permit recovery from a transaction that was genuinely dropped and can no longer land. Preserve the original transaction's validity metadata and add only the small read-only lookup support needed to establish expiration plus reliable absence from chain history. A lower-commitment observed transaction remains pending until its outcome is resolved. Only a demonstrated non-executed, expired transaction may be cleared as expired, after which balances are reloaded before any new swap. If evidence is unavailable or inconsistent, keep it unresolved and log what is missing.
Current `JupiterTransactionOutcomeException` exposes the signature, commitment and outcome but not expiry metadata, and current `SolanaTransactionOutcome` has no expiry result. Add only the structured context/status lookup needed for this burner recovery; do not infer status by parsing exception strings or implement a general reliable-submission framework.
References: [Solana getSignatureStatuses](https://solana.com/docs/rpc/http/getsignaturestatuses) (use historical lookup for later iterations) and [Solana transaction retry guidance](https://solana.com/developers/cookbook/transactions/retry) (establish expiry before creating a replacement transaction).
## Communication errors and diagnostics
Preserve a known signature in structured form when communication fails during confirmation, so that this case can use the same pending-swap reconciliation instead of losing the identity in an `IOException` message. Preserve the underlying cause.
Distinguish errors known to occur before submission from genuinely uncertain post-submission errors. A failed order request or other proven pre-submission error must not cause a process-long suspension; a later scheduled iteration may make a fresh attempt. Do not automatically resume after an ambiguous post-submission error without a trustworthy signature: preserve safe manual handling and clearly identify that limitation.
Improve the relevant logs to show canonical input symbol/UUID, attempted amount, original signature when known, confirmation/reconciliation status, relevant safe cause details, and the next action (check next iteration, resume after resolution, or manual investigation). Do not log credentials, signer responses, or raw signed/unsigned transaction payloads. Do not report `TIMED_OUT` as a definitive failure.
## Verification and scope
Verify offline that an initial timeout is followed by checks of the same signature, success/failure/established expiry permit resumed selection, unresolved/absent-without-expiry/I/O outcomes retain pending state without new swaps, balances are reloaded after resolution, and existing EVE can still be burned while swap outcome remains unresolved. Verify pre-submission errors remain retryable in a later iteration and known-signature confirmation errors retain their structured identity. Verify unknown outcomes cause no automatic resubmission, and preserve normal interruption and one-swap-per-iteration behavior.
Update the affected OpenSpec requirements, JavaDoc and operating documentation through the normal workflow. Compile relevant sources, run strict validation and whitespace checks. Use controlled dependencies; do not perform live financial transactions. No permanent automated tests are requested by this issue.
Keep state process-local, following the current burner model, and document the restart limitation. No persistent transaction journal, rebroadcasting, automatic re-signing of an unresolved operation, new provider routing, direct Raydium swaps, minimum-buy configuration, Ticker changes or unrelated burn/lifecycle refactoring.
Related work: #68, #72, #83 and #90. This issue records implementation scope; implementation and deployment are separate tasks.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem and outcome
The Evelyn IOU burner currently sets a process-long
swapsSuspendedflag when a Jupiter transaction returnsTIMED_OUT. Later hourly iterations never check the known transaction signature again, even if the transaction has since succeeded or failed. Recovery requires a complete Hub restart.Replace this permanent timeout suspension with pending-swap reconciliation: retain the original signature, check its on-chain status in later scheduled iterations, and resume normal input selection once the previous operation has a definitive outcome. Do not confuse checking the same transaction again with submitting the same economic operation again.
This follows the confirmation distinction introduced in #68 and deliberately changes the burner policy from #72. It is separate from #90's token-denominated maxima and the proposed minimum-amount change.
Pending swap and later iterations
JupiterTransactionOutcomeExceptionwithTIMED_OUT, retain the original non-blank transaction signature and the context needed to identify the input and attempted amount. Do not turn it into an untracked process-long suspension.CONFIRMEDor stronger. Reuse the existing Solana/Jupiter confirmation infrastructure and RPC pacing; never callswap()merely to check an earlier operation.Dropped transactions and expiration
An absent signature or another timeout is not proof of failure. Do not clear pending state solely because a transaction is not found, because one hour elapsed, or because its blockhash is no longer valid.
The implementation must also permit recovery from a transaction that was genuinely dropped and can no longer land. Preserve the original transaction's validity metadata and add only the small read-only lookup support needed to establish expiration plus reliable absence from chain history. A lower-commitment observed transaction remains pending until its outcome is resolved. Only a demonstrated non-executed, expired transaction may be cleared as expired, after which balances are reloaded before any new swap. If evidence is unavailable or inconsistent, keep it unresolved and log what is missing.
Current
JupiterTransactionOutcomeExceptionexposes the signature, commitment and outcome but not expiry metadata, and currentSolanaTransactionOutcomehas no expiry result. Add only the structured context/status lookup needed for this burner recovery; do not infer status by parsing exception strings or implement a general reliable-submission framework.References: Solana getSignatureStatuses (use historical lookup for later iterations) and Solana transaction retry guidance (establish expiry before creating a replacement transaction).
Communication errors and diagnostics
Preserve a known signature in structured form when communication fails during confirmation, so that this case can use the same pending-swap reconciliation instead of losing the identity in an
IOExceptionmessage. Preserve the underlying cause.Distinguish errors known to occur before submission from genuinely uncertain post-submission errors. A failed order request or other proven pre-submission error must not cause a process-long suspension; a later scheduled iteration may make a fresh attempt. Do not automatically resume after an ambiguous post-submission error without a trustworthy signature: preserve safe manual handling and clearly identify that limitation.
Improve the relevant logs to show canonical input symbol/UUID, attempted amount, original signature when known, confirmation/reconciliation status, relevant safe cause details, and the next action (check next iteration, resume after resolution, or manual investigation). Do not log credentials, signer responses, or raw signed/unsigned transaction payloads. Do not report
TIMED_OUTas a definitive failure.Verification and scope
Verify offline that an initial timeout is followed by checks of the same signature, success/failure/established expiry permit resumed selection, unresolved/absent-without-expiry/I/O outcomes retain pending state without new swaps, balances are reloaded after resolution, and existing EVE can still be burned while swap outcome remains unresolved. Verify pre-submission errors remain retryable in a later iteration and known-signature confirmation errors retain their structured identity. Verify unknown outcomes cause no automatic resubmission, and preserve normal interruption and one-swap-per-iteration behavior.
Update the affected OpenSpec requirements, JavaDoc and operating documentation through the normal workflow. Compile relevant sources, run strict validation and whitespace checks. Use controlled dependencies; do not perform live financial transactions. No permanent automated tests are requested by this issue.
Keep state process-local, following the current burner model, and document the restart limitation. No persistent transaction journal, rebroadcasting, automatic re-signing of an unresolved operation, new provider routing, direct Raydium swaps, minimum-buy configuration, Ticker changes or unrelated burn/lifecycle refactoring.
Related work: #68, #72, #83 and #90. This issue records implementation scope; implementation and deployment are separate tasks.