Repository navigation
feat: error/empty states audit, indexer-lag notice (M3-21) - #32
Merged
Merged
Conversation
Audited each of M3-21's five named states against the actual message-key and error-mapping code: trustline failure, expired, revoked, and suspended were already clearly covered (claim-logic.ts's CONTRACT_ERRORS, preflight's payee_active/payout_trustline_authorized messages, lock refundAvailable messages), and per the SDK's own preflight doc comment, the checks that matter are chain-backed and blocking, never indexer-sourced. Indexer lag was the one real gap: added indexerLagging() (reads the indexer's /health status) and a shared LagNotice component, shown on /send, /request, and /payee when the indexer reports anything other than ok. Informational only; no money decision depends on it.
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
2 participants
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.
What and why
M3-21asks for clear guidance across five states: trustline failure, expired, revoked, suspended, indexer lag. Rather than assume these needed new code, audited each against the actual message keys and error-mapping logic first.Changes
Audit findings (no code changes needed for four of the five):
claim-logic.ts'sCONTRACT_ERRORSmap pluserrorTx's plain-language "can't receive this asset yet" phrasing (release side);preflight.payout_trustline_authorized.*has a distinct message per failure mode,missing/not_authorized/limit(send side).pages.claim.errorExpired,pages.lock.refundAvailable.Expired.pages.claim.errorPayeeNotActive(the contract's singlePayeeNotActiveerror, covering both),preflight.payee_active.revoked/.suspended,pages.lock.refundAvailable.Revoked/.SuspendedTimeout.preflight.jsdoc comment,payee_activeandpayout_trustline_authorizedare chain checks and block a send on failure; onlyrecent_payout_changeandduplicate_ref_hashare indexer-sourced, and those are already downgraded towarnseverity. So none of the above is at risk from indexer lag in the first place.The one real gap, fixed here:
lib/indexer/index.ts: newindexerLagging(), reading the indexer's own/healthendpoint (status: "ok" | "lagging" | "unknown"), defaulting to "possibly stale" on any fetch/parse failure so a broken health check can never silently hide a real lag.components/indexer/LagNotice.tsx: shared, shown on/send,/request,/payeewhenindexerLagging()is true. Purely informational.Hard rules / invariants touched
None. Confirms, rather than changes, hard rule 3: every blocking decision already reads chain state; this notice only ever concerns list-browsing UX.
Tests
pnpm lint,pnpm typecheck,pnpm test(108/108, 5 new inlib/indexer/index.test.ts: ok → false, lagging → true, non-ok HTTP → true, network failure → true),pnpm buildall green.Ran locally against the real indexer (
.env.localpointed at the live Railway instance): currently healthy (lagLedgers: 1,status: "ok"), and confirmed the notice correctly does not show, while/send,/request,/payeestill list payees correctly with the added parallel/healthfetch alongside the existing list fetch.Docs / ADR
None needed.
Roadmap
M3-21→DONE. Phase 4 App: 12→13 DONE, 8→7 TODO (46%→50%). All rows: 42→43 DONE, 119→118 TODO (24%, unchanged after rounding). Changelog entry added with the full audit trail.Assumptions and open questions
Didn't artificially degrade the real production indexer just to screenshot the "lagging" banner; that branch is covered by the unit tests instead. If someone wants to see it live, the indexer's
/healthendpoint would need to actually report non-ok(e.g. during a real deploy or outage).