Skip to content

[Quality][High] Improve application shell navigation resilience: transactional invariants and recovery #1817

Description

@1nonlypiece

Problem

The current application shell navigation resilience implementation is a production-quality risk area: Global navigation must preserve focus, route state, loading behavior, and safe recovery when a protected page fails.

This issue requires meaningful implementation and focused tests. Typo-only, documentation-only, formatting-only, dependency-only, and cosmetic changes do not satisfy the scope.

Objective

make state transitions deterministic, atomic, and recoverable across retries, refreshes, and interrupted wallet operations for the implementation anchored at src/components/shell/AppShellLayout.tsx; src/components/shell/AppSidebar.tsx.

Scope

  • Establish the feature's explicit state, data, authorization, and failure invariants.
  • Define the state machine and invariants for every success, rejection, cancellation, and retry path.
  • Prevent duplicate submissions and stale responses from creating contradictory client state.
  • Add failure recovery that preserves user intent without silently repeating an on-chain action.
  • Keep the change focused on this feature and preserve unrelated public behavior.

Acceptance criteria

  • The implementation defines and enforces the relevant invariants for normal and adversarial inputs.
  • Define the state machine and invariants for every success, rejection, cancellation, and retry path.
  • Prevent duplicate submissions and stale responses from creating contradictory client state.
  • Add failure recovery that preserves user intent without silently repeating an on-chain action.
  • Automated tests cover success, failure, boundary, retry, and permission behavior applicable to this feature.
  • The PR includes validation commands, design tradeoffs, and any remaining limitations.
  • The PR references this issue using Refs #<issue-number>.

Priority

High — determined by the potential impact on correctness, user funds or data, security, availability, and implementation depth.

Non-goals

  • Do not make typo-only, documentation-only, formatting-only, dependency-only, or cosmetic changes.
  • Do not remove tests merely to make CI pass.
  • Do not introduce secrets, credentials, unsafe network defaults, or unrelated refactors.

Contributor application

Before starting, comment with relevant experience, a concise implementation approach, the main risks or tradeoffs, and an estimate for opening the first draft PR. Wait for maintainer assignment before coding.

Submission requirements

  • Use PR title format: [#<issue-number>] <short summary>.
  • Address every acceptance criterion in the PR description and implementation.
  • Include focused automated tests and validation results.
  • Explain any unavoidable limitations or pre-existing CI failures.
  • Address maintainer review feedback before requesting final review.

Quality evaluation will consider scope adherence, implementation quality, test depth, security, correctness, review responsiveness, and follow-up stability.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Stellar WaveIssues in the Stellar wave program

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions