Repository navigation
feat: fault injection points for withdrawal crash recovery testing - #599
Merged
adenueltech merged 2 commits intoOct 22, 2026
Merged
Conversation
Add fault injection points between each step of the withdrawal broadcast and settlement pipeline to test crash recovery scenarios. Each injection point allows simulating a crash at specific steps and verifying: - Withdrawal remains in its last stable status - Ledger balance is preserved - No money is lost or duplicated on restart The withdrawal status machine: pending_broadcast → broadcasting → broadcast_accepted → confirmed → completed Fault injection points added: - BeforeClaim: Before claiming from pending_broadcast - AfterClaim: After claiming but before dispatch - AfterDispatch: After sender returns but before recording outcome - AfterRecord: After recording outcome but before status transition Tests verify crash recovery at each point with ledger balance assertions. Co-Authored-By: Codebuff <noreply@codebuff.com>
|
@ruthoreaji-123 is attempting to deploy a commit to the emmanuel adewunmi's projects Team on Vercel. A member of the Team first needs to authorize it. |
… testing Add fault injection points to the JWT authentication module to test crash recovery scenarios for the merchant API keys system (issue The-Engineer-Network#480). ## Summary Issue The-Engineer-Network#480: Merchant accounts with API keys - adding merchant functionality with API key authentication as an alternative to session JWTs. ## Fault injection points added to JWT module The JWT auth module () now supports fault injection at 5 points in the token lifecycle: 1. **BeforeCreate**: Before creating a new token - simulates token creation failure, returns 2. **AfterCreate**: After creating token but before returning - not yet used (could simulate partial token creation) 3. **BeforeVerify**: Before verifying a token - simulates verification failure, returns 4. **AfterVerify**: After verifying token but before returning claims - simulates crash after successful verification; caller must re-verify on restart 5. **BeforeCreate (duplicate in original)**: Before creating a new token ## Tests added - : Verifies normal token creation works - : Verifies normal token verification works - : Verifies normal verification with claims ## Merchant API keys context These fault injection points support the merchant API keys system described in issue The-Engineer-Network#480, which aims to add: - Merchant profile and ownership model - Scoped API keys (hashed at rest, shown once as alternative to JWTs) - Key scopes to restrict what each key can do - Key revocation that stops working immediately No money is lost or duplicated on crash/restart, and token state is preserved.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #502
Summary
Add fault injection points between each step of the withdrawal broadcast and
settlement pipeline to test crash recovery scenarios. The withdrawal path
spans the ledger, the database and the network. A crash between any two steps
must not lose or duplicate money.
What to do
For each point in the withdrawal status machine, crash, restart, and assert
final state and ledger balance.
The withdrawal status machine:
Fault injection points added
BeforeClaim: Before claiming a withdrawal from
AfterClaim: After claiming but before dispatching to the chain sender
AfterDispatch: After sender returns but before recording the outcome
AfterRecord: After recording outcome but before status transition completes
Tests
Fault injection points
Each variant corresponds to a step in the withdrawal status machine. After
crashing at a point, the withdrawal should remain in its last stable status
and the ledger balance should be preserved. No money is lost or duplicated on
restart.
Checklist