Conversation
…rotocol#187, part 1) Adds the deterministic failure knobs and the Send-flow matrix that were promised in the wave application. Structured as PR 1 of a small series so the pattern can be reviewed before it is replicated across the remaining flows. ## Fixture extensions (e2e/fixtures.ts) Freighter mock: - `network`: 'TESTNET' | 'PUBLIC' | 'FUTURENET' (default TESTNET). Drives the wrong-network path via a new `getNetworkDetails()` method that returns the matching Networks passphrase, so `StellarWalletContext.isNetworkMismatch` fires and `NetworkMismatchModal` opens. - `sessionExpired`: reports `isAllowed: false` and clears `getAddress` until the user re-authorises via `requestAccess`, mirroring a stale wallet session. - Adds `isAllowed()` and `getNetworkDetails()` so the wallet context's init/reconnect paths are actually observable in tests. Horizon / Soroban RPC mock: - `timeoutMs`: delays every Horizon and Soroban route response by that many ms so specs can drive the "RPC timeout" branch without wall- clock flakiness. - `insufficientBalance`: /accounts/* returns a tiny XLM balance so the app's own `balanceError` fires; POST /transactions returns `tx_insufficient_balance` on submit. - `missingTrustline`: account exists but reports only native XLM; submit returns `op_no_trust` under the transaction result codes. - Precedence on submit is trustline > balance > explicit `txErrorCode` > success so a spec that sets multiple knobs still gets a deterministic assertion. ## Send-flow matrix (e2e/send-failures.spec.ts, new file) One spec per failure mode: - Signature rejected: the wallet throws; the app clears pending, keeps the "Send Privately" CTA actionable, surfaces the reject message. - RPC timeout: 20 s stall; assert the button re-enables and a retry/timeout/failure signal is visible within budget. - Wrong network: wallet reports PUBLIC; assert the Network Mismatch modal renders and the success screen never appears. - Insufficient balance: inline "Insufficient XLM ..." validation and a disabled submit CTA — never reaches signing. - Missing trustline: marked `test.fixme` because native-XLM send has no trustline concept for the source; the spec documents the intended behaviour for when credit-asset send lands. - Stale session: connect CTA stays visible instead of a silent restore; a fresh click resumes and the recipient input becomes reachable. ## What is NOT in this PR Per the application text, deliberately scoped so the pattern is reviewable first. Follow-up PRs apply the same matrix to Receive, Schedule, and Vault. `batch` is mentioned in the issue but no /batch route or batch component exists in src/ today. ## Verification note On this local environment `pnpm exec playwright test` also fails against the existing e2e/stellar.spec.ts (page renders blank), which appears to be a pre-existing dev-server / Vite issue on `develop` unrelated to these changes; the Chain switcher and Connect button are not present in the rendered DOM at test time for either the existing specs or the new ones. Fixtures and specs compile cleanly and use only public wallet-context / route APIs, so they will run against a working dev-server without further modification. Refs wraith-protocol#187
|
@Labi-Joy is attempting to deploy a commit to the truthixify's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
@Labi-Joy Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
Contributor
|
This currently covers only Send and leaves trustline as fixme. The issue requires the failure matrix for send, receive, batch, schedule, and vault. Please complete those flows and remove the skipped case. |
Contributor
|
Closing this older version so review stays on #204. Please continue the remaining failure-path work there. |
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 #187
Summary
Part 1 of the failure-path e2e work I applied to. Adds deterministic mock knobs for the failure modes the issue names, plus the full Send-flow matrix that uses them. Structured so the pattern (fixture shape, spec skeleton, recovery-assertion pair) can be reviewed before it is replicated across the remaining flows.
Fixture extensions (`e2e/fixtures.ts`)
Freighter mock
Horizon / Soroban RPC mock
Send-flow matrix (`e2e/send-failures.spec.ts`, new)
One spec per failure mode; every spec asserts recovery is reachable AND no stuck spinner is left behind (the two acceptance-criteria bullets):
Trustline is marked `test.fixme` because native-XLM send has no trustline concept on the source side. The spec documents the intended behaviour so a future credit-asset PR just removes the `fixme`.
What is NOT in this PR
Per my application text, this is deliberately scoped so the pattern is reviewable first. Follow-up PRs apply the same matrix to Receive, Schedule, and Vault (each has an existing e2e file to slot into).
`batch` is mentioned in the issue but there is no `/batch` route or batch component in `src/` today — the flow needs to ship before a failure matrix can meaningfully cover it. Happy to open a separate issue for that if it is in scope.
CI
Playwright config already runs `e2e/**/*.spec.ts`, so this file is picked up automatically by `pnpm test:e2e`. No CI changes required.
Verification note
On my local environment `pnpm exec playwright test` also fails against the existing `e2e/stellar.spec.ts` — the app renders a blank white page under Playwright and the Chain switcher / Connect button are never in the DOM at test time. This appears to be a pre-existing dev-server / Vite issue on `develop` unrelated to the changes here (verified by stashing my changes and re-running). The fixtures and specs compile cleanly and use only public wallet-context / route APIs, so they should run against a working dev-server without further modification. Happy to help debug the dev-server issue as a follow-up if it is in scope.