fix: refresh receive after payment

[ben-kaufman]

Description

• Invalidate a settled wallet Lightning invoice before publishing its payment event so stale invoices are not restored.
• Carry settlement metadata with the exact node event instead of shared mutable state, preventing adjacent payment events from taking the receive context of another event.
• Persist the cached BOLT11 payment hash with the invoice so settlement correlation does not depend on decoding during event handling; migrated cache entries fall back to direct BOLT11 parsing.
• Clear only the exact settled invoice in cache and memory, preserving a replacement invoice generated while the event is still being processed.
• Track the invoice shown by each receive sheet so a paid sheet closes reliably without dismissing a replacement sheet or a newly edited request.
• Coordinate received-payment presentation through a synchronous in-process claim on the UI dispatcher, then mark it seen only after the notification or sheet is handed off.
• Refresh the reusable receive address and BIP21 request after the current Lightning invoice or on-chain address is used.

Preview

Not applicable; this fixes receive-state lifecycle behavior without changing the UI layout.

QA Notes

• ./gradlew compileDevDebugKotlin
• ./gradlew testDevDebugUnitTest
• ./gradlew detekt --rerun-tasks (passes with the repository baseline findings)
• git diff --check
• Regression coverage in AppCacheDataTest.kt, CacheStoreTest.kt, LightningRepoTest.kt, WalletRepoTest.kt, AppViewModelSendFlowTest.kt, LightningNodeServiceTest.kt, and NotifyPaymentReceivedHandlerTest.kt

[greptile-apps]

Greptile Summary

This PR updates receive state after Lightning and on-chain payments. The main changes are:

• Invalidates a settled Lightning invoice before publishing its event.
• Carries settlement metadata on each node event.
• Preserves replacement invoices during cache and memory updates.
• Tracks the invoice associated with each receive sheet.
• Defers payment marking until notification or sheet presentation.
• Refreshes reusable receive requests after payment.

Confidence Score: 4/5

The foreground/background payment handoff can omit both notification and in-app presentation.

• Activity transitions can make the service and UI both decline the same payment.
• Activity-store failures suppress the sheet without retrying.
• Decode failures leave a settled receive request active.

LightningNodeService.kt, AppViewModel.kt, and LightningRepo.kt

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/androidServices/LightningNodeService.kt	Rechecks foreground state before marking and posting a payment notification, leaving a handoff race with the UI.
app/src/main/java/to/bitkit/domain/commands/NotifyPaymentReceivedHandler.kt	Separates presentation eligibility from marking the payment as seen.
app/src/main/java/to/bitkit/repositories/LightningRepo.kt	Invalidates matching cached invoices and publishes settlement metadata with each event.
app/src/main/java/to/bitkit/repositories/WalletRepo.kt	Conditionally clears only the matching in-memory invoice and preserves replacements.
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Tracks receive-sheet invoice identity and defers sheet display until the payment is marked.
app/src/main/java/to/bitkit/data/CacheStore.kt	Adds atomic expected-invoice invalidation while preserving unrelated receive data.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant Node as LightningRepo
    participant Service as LightningNodeService
    participant Activity as CurrentActivity
    participant UI as AppViewModel
    Node->>Service: PaymentReceived
    Service->>Activity: Check foreground state
    Activity-->>Service: Foreground
    Service-->>Node: Skip notification
    Activity-->>Activity: Pause and clear current activity
    Node->>UI: NodeEventUpdate
    UI->>Activity: Check foreground state
    Activity-->>UI: Background
    UI-->>UI: Skip sheet
    Note over Service,UI: Neither path presents the payment

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant Node as LightningRepo
    participant Service as LightningNodeService
    participant Activity as CurrentActivity
    participant UI as AppViewModel
    Node->>Service: PaymentReceived
    Service->>Activity: Check foreground state
    Activity-->>Service: Foreground
    Service-->>Node: Skip notification
    Activity-->>Activity: Pause and clear current activity
    Node->>UI: NodeEventUpdate
    UI->>Activity: Check foreground state
    Activity-->>UI: Background
    UI-->>UI: Skip sheet
    Note over Service,UI: Neither path presents the payment

Loading

_{Reviews (1): Last reviewed commit: "fix: correlate receive settlement events" | Re-trigger Greptile}

[jvsena42]

Nothing blocking so far, still haven't tested

[jvsena42]

AppViewModel.handlePaymentReceived still calls activityRepo.handlePaymentEvent(paymentHash). The same payment is processed twice with different keys. Is this intentional?

[jvsena42]

nit: could remove the key from presentationClaims

[jvsena42]

could extract this duplicated logic to a present method like:

suspend fun present(
    command: NotifyPaymentReceived.Command,
    canPresent: () -> Boolean = { true },
    block: suspend () -> Unit,
): Boolean {
    if (!claimPresentation(command, canPresent)) return false
    block()
    recordPresentation(command)
    return true
}