[ovitrif]

Description

• Bumps the Breez SDK from 0.28.2 to 0.28.3. From 0.28.2 it brings:
  • breez/spark-sdk#1315: fetchLightningSendStatus, which asks the Spark operators whether this wallet sent an invoice over Lightning, without the local payment list.
  • breez/spark-sdk#1309: swaps use version 2 adaptor signing. No app code changes for it.
  • breez/spark-sdk#1307: token metadata renamed to PaymentTokenMetadata, with extra fields. Bitkit doesn't use it. The rest is docs and CLI samples.
• The restore hold from feat: add spark via breez sdk #1128 now asks the operators. After a restore, Spark's list can lack a send it made before the restore, so both rails refused every still-valid invoice dated before the restore that Spark hadn't listed, until it expired. Now, for such an invoice, both rails call fetchLightningSendStatus before paying:
  • Completed, pending or failed counts as sent, and the payment is refused as before.
  • No send lets it pay, unless the send prefers Spark (regtest only) and the SDK quotes a Spark transfer for the invoice, which it does only when the invoice carries a Spark address.
  • Any error, or no Spark to ask, refuses it.
• The refusal that waited for Spark's first sync after a restore is gone: the hold above covers those invoices, and kept, it would refuse invoices the operators show unsent. sparkHistoryUnseededSince stays, so the sends Spark lists keep holding the node across a relaunch.

Breez docs caveat: fetchLightningSendStatus sees only Lightning sends. A payment the SDK made as a direct Spark transfer to the invoice's Spark address isn't found, which is why "no send" pays only when that can't have happened. A Spark-preferring send pays that address by transfer, and Bitkit prefers Spark only on regtest, so on mainnet "no send" always pays and the extra check never runs.

Design

N/A — no UI changes.

Preview

N/A

QA Notes

Automated Checks

• ChannelFreeRailTests, for a valid invoice dated before the restore, with the operators' calls counted:
  • completed, pending and failed are refused on both rails;
  • no send pays over the node, and over Spark;
  • no send that Spark may have paid by transfer is refused on both rails;
  • a status or transfer check that fails is refused on both rails, as is a Spark build with no rail to ask;
  • testOnlyASparkPreferringSendPaysAnInvoicesSparkAddressByTransfer covers the four combinations of the transfer check.
• By default the fake's operators are unreachable, so a test that sets no answer is refused rather than paid.
• ChannelFreeRailTests and SparkConfigTests pass locally on a simulator; SwiftFormat lint is clean.

[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-12T16:30:03.087227Z	c15b1fc	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.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c15b1fce23

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[greptile-apps]

Confidence Score: 5/5

[High impact] No new actionable issue remains beyond the overlapping Spark-send risk explicitly deferred by ovitrif.

Summary

Updates Breez SDK to 0.28.3 and checks the operators before allowing an unlisted, pre-restore invoice to be paid.

• Bitkit checks Spark’s operators before paying a pre-restore invoice.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Unlisted pre-restore invoice] --> B{Operators answer?}
  B -->|Error or any send| C[Refuse payment]
  B -->|No send| D{Direct Spark transfer possible?}
  D -->|Yes or check fails| C
  D -->|No| E[Continue normal send checks]

Loading

_{Reviews (7) · Last reviewed commit: "chore: breez sdk 0.28.3" · Reviewed by Greptile}

[ovitrif]

SwiftFormat crashed on the runner (exit code 139) before linting, so I reran the job; nothing in the diff changed.

[ovitrif]

Milestone 3.2.0: this PR is the iOS twin of synonymdev/bitkit-android#1893 and moves the Spark integration to Breez SDK 0.28.3, which adds fetch_lightning_send_status and moves swaps to v2 FROST adaptor signing, both needed for the 3.2.0 Spark release. It closes no issue, so the milestone sits on this PR.

[ovitrif]

#1128 merged into master as 96225a1 and its branch was deleted, so this PR now targets master. Its diff is unchanged: the same commit and 5 files, with no conflicts.

[ovitrif]

The retarget e2e run stopped at its merge-checkout check: the checked-out merge no longer matched the PR base after the retarget to master. No test ran, so I reran it.

[talosmachina]

No findings. Bumps the Breez SDK to 0.28.3 and lets the restore hold pay a pre-restore invoice once the Spark operators show no Lightning send of it and, on a Spark-preferring build, the SDK quotes no Spark transfer for it. Reviewed c15b1fc, full tier, static: iOS does not build on this reviewer's Linux host, so this is reasoned from the code, the SDK source and CI.

What I checked, and 5 candidates I ruled out

Read in full: the diff of LightningService.swift, SparkManager.swift, ChannelFreeRailTests.swift, the package pins; settledEarlierAttempt whole at this head.
SDK source checked (breez/spark-sdk at tag 0.28.3): fetch_lightning_send_status in crates/breez-sdk/core/src/sdk/payments/lightning_send_status.rs, prepare/bolt11.rs, the Spark address extraction in crates/spark/src/services/lightning.rs.
CI: SwiftFormat green on its rerun (the first run segfaulted inside swiftformat_linux, exit 139, not a lint finding). e2e-status is red because the retarget run's build-local stopped at "Checked-out merge does not match the PR's current base and head", a checkout precondition, before any test ran. Run Tests and the integration tests were still pending when this was written.

Ruled out

• Transfer check proxy: the SDK sets spark_transfer_fee_sats to Some(0) exactly when it extracts a Spark address from the invoice, so paysBySparkTransfer(prefersSpark:sparkTransferFeeSats:) matches what a preferSpark send does, and it only prepares a payment when prefersSpark (regtest).
• "No send" read too loosely: the SDK returns no status only for an empty preimage request list, an unknown status is an error, and any returned request is Failed. refuseUnverifiedRestoredInvoice refuses on every status and on every thrown error, rethrowing its own refusal unchanged.
• Dropping the unseeded refusal leaves a gap: the restore entry point sets sparkHistoryUnseededSinceKey and sparkRestoredAtKey together (LightningService.swift:1217), and clearSparkRestore clears both, so an invoice the removed branch refused still reaches the operators' check.
• Rail not started: falling back to channelFreePaymentHistory keeps the operators reachable while the send rail is down, and with neither set but Spark supported it throws ChannelFreeRailUnavailable and refuses, which testAPreRestoreInvoiceIsRefusedWhenNoSparkRunsToAsk covers.
• Node already paid it: the operators are still never asked when the node's row is succeeded (isPaidOverTheNode), so a paid invoice reads as paid rather than refused.

Merge confidence: 3/5, no findings, but e2e-status is red on a checkout mismatch rather than a test and the unit suite had not reported when this was written.

Reviewer model: Claude Opus 5.5
Reasoning effort: Not exposed (the run metadata available to this reviewer does not carry it)

[coreyphillips]

Two independent reviews, nothing blocking a merge.

worth doing, does not block

• No test covers paying while Spark can't list right after a restore (BitkitTests/ChannelFreeRailTests.swift:1387-1394)

[ovitrif]

Restarted the retarget E2E with a fresh dispatch: the earlier run and its rerun both stopped at the checkout check, because master moved after the merge sha was taken. No test had run.

[ovitrif]

Closing and reopening this PR to make GitHub rebuild its merge commit. It still merged onto the old Spark base (bbf02ca) after the retarget to master, so the retarget E2E stopped at its checkout check every time. Approvals and code stay as they are.

[ovitrif]

Reopened this PR twice more to clear stale checks. The runs the first reopen started had checked out the old merge commit and failed their checkout check, and a rerun repeats that commit. So the first reopen rebuilt the merge commit on current master (21e87d6), and the second started fresh E2E and integration runs on it. Code and approvals are unchanged.

[ovitrif]

Closing and reopening to rebuild the merge ref on current master (#1309 just merged), then rerunning the retarget E2E so the failed e2e-status check from the cancelled run is replaced.

[ovitrif]

Merging: approved on this head; required checks green on a merge with current master (SwiftFormat crash, one ProfileRecovery UI test and the @transfer_2 E2E case passed on rerun); no open threads.