[ovitrif]

Description

Fixes four Spark follow-ups from the reviews of #1309 and #1312, matching the Android twins (synonymdev/bitkit-android#1898, synonymdev/bitkit-android#1903).

• Emergency exit fee ask during a Redo hold (Fixes bug: spark exit fee ask stays up during a redo hold the held funding paid #1313): a Redo rebuild that the funding the exit already holds pays for now moves the exit to running, and its fee ask and notification are withdrawn. That includes an ask raised by the Redo's own short build or a later one in the hold. A later build that comes up short asks again.
• Overlapping Spark sends of one invoice (Fixes bug: overlapping spark sends of one invoice both go out #1315): a Spark send is refused at admission when another Spark send of the invoice was recorded since its checks, so only one goes out. The refused send returns the other send's outcome: paid when Spark lists it paid, the failure when it failed and no send of the invoice was live before, during or after the read, else pending.
• Retry after a failed send of a pre-restore invoice (Fixes bug: a failed send locks out a pre-restore invoice #1316): a FAILED operator status counts as unsent, so the invoice can be paid again on either rail.
• Restore hold while Spark can't list (Fixes test: restore hold asks the operators while spark can't list #1314): tests for the operators' answer when Spark hasn't synced since the restore, and a journey for paying a pre-restore invoice after a restore.

QA Notes

• New unit tests in ChannelFreeRailTests, SparkExitTests and SparkExitReviewTests; each fails when its own fix is reverted.
• ChannelFreeRailTests and the offline SparkExit* test classes pass on an iPhone 17 Pro simulator (iOS 26.5).
• SwiftFormat 0.64.6 lint passes on the changed files.
• The new journey journeys/send/restored-wallet-pre-restore-invoice.xml is written but not run on a device yet.

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-13T01:53:37.499222Z	1ae9f78	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The changes affect Spark invoice payments and emergency-exit fee reminders.

The PR appears safe to merge, with a non-blocking gap in repeated funding notifications.

Findings

1.  Repeated funding alerts stay silent ▶

Summary

This PR fixes Spark payment retries and Redo exit funding asks.

• Only one overlapping Spark send of an invoice reaches the rail.
• Restored wallets can retry invoices Spark confirms failed.
• A funded Spark exit Redo rebuild clears its fee ask.

One non-blocking issue remains: a withdrawn funding alert cannot fire again when the exit later asks for the same amount.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Spark send passes earlier checks] --> B{Another Spark send recorded meanwhile?}
  B -->|No| C[Record and submit send]
  B -->|Yes| D[Refuse submission and read payments]
  D --> E{Listed outcome}
  E -->|Paid| F[Return payment hash]
  E -->|Failed and no live send| G[Return failure]
  E -->|Unknown or another send live| H[Keep pending]

Loading

_{Reviews (1) · Last reviewed commit: "fix: spark exit redo hold and overlappin..." · Reviewed by Greptile}

[coreyphillips]

Two independent reviews, nothing blocking a merge.

[talosmachina]

No findings. Withdraws the Redo hold's fee ask once the held funding pays for a build, refuses a second Spark send of one invoice at admission and hands it the first send's outcome, and treats an operator FAILED status as unsent for pre-restore invoices. Reviewed 1ae9f78, full tier, static: bitkit-ios does not build on this Linux host, so nothing was run here.

What I checked, and 5 candidates I ruled out

Read in full: LightningService.send (Spark branch), admitSend, settledRecordedRailSend, isSendLive, attemptsRecorded, channelFreeRailPayments, refuseUnverifiedRestoredInvoice, SparkManager.send and SparkSpends.run, SparkExitDriver.tick funding branch, check Redo verdict, build, askForFunding, holdsRedo, SparkExitManager.tick, isFundingAskWithdrawn, scheduleReminders, SparkExitMath.reminders
Call sites traced: admitSend (Spark and node paths), isFundingAskWithdrawn (one caller, SparkExitManager.tick), holdsRedo (three, isBuilt only on the two post-build ones)
Twin: matches synonymdev/bitkit-android#1898 and #1903 on isRedoAsk and the withdrawal predicate
CI: SwiftFormat, validate, integration tests and build-local green; Run Tests still running when this was posted

Ruled out

• Admission refusal of the first send itself: recordRailAttempt runs only after admitSend passes, so a send is never refused for its own record; mark is read before the checks.
• Refused send leaking railSendsInFlight: the new path calls endRailSend and sets isRailSendEnded, the defer skips the second call, and the throw before that branch still reaches the defer.
• isRefusedAtAdmission caught by the ChannelFreeRailSendRefused arm: admitSend throws NodeError.DuplicatePayment, so the earlier arm never takes it, and beforeSubmission errors still go through spends.run before the SDK call.
• Stale isRedoAsk widening isFundingAskWithdrawn: it is cleared at the start of the next tick once the phase carries no funding, and the predicate also requires record.funding == previous.funding, so a real top-up never reads as a withdrawal (asserted in the existing hold test).
• Re-ask after a withdrawal posting no notification: already raised by Greptile on SparkExitManager.swift:1586; not repeated here.

Merge confidence: 4/5, no findings, but the static review could not run the new ChannelFreeRailTests and SparkExit* cases and Run Tests had not finished at this head.

Reviewer model: claude-opus-5-5
Reasoning effort: low

[ovitrif]

Merging: approved on this head, required checks green (the unit-test job's earlier failures were four different short timeouts in suites this PR doesn't touch; the rerun passed), no open threads. Greptile's reminder point is tracked in #1324.