fix: expose rejected incoming payment requests

[ovitrif]

Fixes #1209

Description

• Records stable parse, resolution, and presentation failure reasons while redacting payment-request counterparties.
• Retries explicitly opened payment requests 15 times before showing localized terminal feedback and keeping the request actionable.
• Adds accessibility tags, regression coverage, documentation, and a reproducible rejected-request journey.

Preview

pr1209-terminal-recovery-preview.mp4

QA Notes

Manual Tests

• 1. Sender Receive → Payment Request Details → request 1 sat from a saved contact → Payment Request Sent: request reaches the receiver.
• 2. Sender Settings → disable Paykit → receiver Home → Payment Requests in-sheet → tap Pay: 15 attempts run at two-second intervals, then the localized unavailable toast appears.
• 3. Payment Requests in-sheet after terminal feedback → use the same row: it remains available for retry or dismissal.

Automated Checks

• Unit tests added in PaykitPaymentRequestDiagnosticsTest.kt: verify parse and presentation diagnostics redact valid and invalid counterparties.
• Unit tests modified in PaykitPaymentRequestRepoTest.kt and PublicPaykitRepoTest.kt: cover stable parse and resolution failure reasons.
• Unit tests modified in AppViewModelSendFlowTest.kt: cover 15 explicit attempts, localized terminal feedback, and request-sheet restoration.
• Instrumented tests modified in PaymentRequestsScreenTest.kt: cover stable request, Pay, and Dismiss accessibility tags; the focused class passes 5/5 on API 37 and 5/5 on API 36.
• CI: standard build, unit test, lint, detekt, and E2E checks pass.

The full two-wallet journey passed on API 37: a delivered 1-sat request became unresolvable after its sender disabled Paykit, produced 15 redacted resolution_failed attempts, showed terminal feedback, and returned to the request sheet with the same row actionable. The full connected suite remains blocked by the unrelated existing OnchainServiceTests.testDeriveRegtestDescriptorsForSupportedAccountTypes failure; the focused payment-request UI class passes on API 37 and API 36.

[greptile-apps]

Greptile Summary

The PR adds categorized, redacted diagnostics for rejected incoming Paykit requests and bounded retries with localized terminal feedback while preserving the request for manual action.

• Refactors incoming-request parsing into explicit success and rejection results.
• Adds reason-specific diagnostics for parsing, resolution, and presentation failures.
• Retries explicitly opened requests up to 15 times and restores the originating request sheet when appropriate.
• Adds stable accessibility tags, regression tests, documentation, and a rejected-request journey.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/repositories/PaykitPaymentRequestRepo.kt	Replaces nullable request parsing with categorized results and redacted diagnostics while preserving active-request and history eligibility.
app/src/main/java/to/bitkit/repositories/PublicPaykitRepo.kt	Maps payment-opening outcomes to stable resolution and presentation failure reasons.
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Adds bounded manual presentation retries, reason-specific diagnostics, terminal feedback, and conditional request-sheet restoration.
app/src/main/java/to/bitkit/ui/screens/paymentrequests/PaymentRequestsScreen.kt	Adds stable test and accessibility tags to request rows and incoming-request actions.
app/src/test/java/to/bitkit/viewmodels/AppViewModelSendFlowTest.kt	Covers the 15-attempt terminal path, diagnostics, localized feedback, sheet restoration, and full-screen behavior.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Incoming Paykit request] --> B[Parse request terms]
    B -->|Rejected| C[Log redacted parse reason]
    B -->|Accepted| D[Show actionable request]
    D --> E[User selects Pay]
    E --> F[Resolve payment details]
    F -->|Opened| G[Normal send flow]
    F -->|Unavailable| H[Log redacted failure]
    H --> I{Attempts remaining?}
    I -->|Yes| J[Retry after delay]
    J --> F
    I -->|No| K[Show localized terminal feedback]
    K --> L[Restore request surface when applicable]
    L --> M[Request remains available for retry or dismissal]

Loading

_{Reviews (3): Last reviewed commit: "test: cover valid pubky redaction" | Re-trigger Greptile}

[piotr-iohk]

QA LGTM.

Tested latest (95788b9) Pixel emu against iOS codex/paykit-payment-proofs, regtest. Incoming 1 sat + 27k from iOS. Tap Pay on an unresolvable request:

• 15 resolution_failed attempts at ~2s
• Stopped retrying requested incoming Paykit payment request after '15' presentation attempts
• Toast: "Payment Request" / "The payment request is no longer available."
• Row stays with Pay and Dismiss

Opening a still-resolvable request goes to Confirm with swipe disabled. That is the master isAmountInputValid hole, not this PR. Already fixed on #1178 (e04115003); standalone: #1218 / #1221. Not a blocker for this toast/retry path.

[piotr-iohk]

Please resolve conflicts.

[piotr-iohk]

QA LGTM.

Latest (800b902d) after the conflict rebase.

I already ran the full unresolvable-request journey on 95788b9 (15 × ~2s, redacted resolution_failed, unavailable toast, row stays with Pay/Dismiss). The only commit since that QA is the valid-pubky redaction test. Rebase onto master (incl. #1178) does not change the toast/retry path.

This pass:

• Installed 800b902d on Pixel_6 emu. Wallet restored (Alice / pubkyff…qyqnsuy), contact payments on, Paykit session re-signed and published btc-regtest-p2wpkh.
• Focused unit tests pass: PaykitPaymentRequestDiagnosticsTest, PaykitPaymentRequestRepoTest, PublicPaykitRepoTest, AppViewModelSendFlowTest.
• Journey XML parses.

CI green on this head, including local + staging E2E.

Happy to approve.

[ben-kaufman]

Could we apply the incoming-request early return to these branch-specific errors too? On the final attempt, clearIncomingPaymentRequestTarget() enqueues PaymentRequestUnavailableToast, then DuplicatedBip21Toast replaces it. The same order remains for invalid addresses and expired invoices. Could we skip those scan-error toasts when the helper reports an incoming request and assert the terminal toast is last?

[ben-kaufman]

Could we still close Sheet.Send when this runs from confirmation? clearIncomingPaymentRequestTarget() skips hideSheet() whenever a request context existed. During confirmation that clears the context but leaves the Send sheet open in stale payment-request state, so the user needs another Pay tap to close it. Could we distinguish an already-visible Send sheet and cover it in the confirmation mismatch tests?