fix: advertise the plain invoice_expiration_window

[21Mill]

Closes #895.

The bug

The kind-38385 info event filled the invoice_expiration_window tag from
ln_settings.hold_invoice_expiration_window — a copy-paste from the tag two
entries above, so both tags published the same number.

The two are independent settings: the hold invoice window is the lifetime of
the invoice the seller pays, while invoice_expiration_window is the minimum
remaining lifetime a buyer payout invoice must have, enforced in
src/lightning/invoice.rs. So the one number a client needs in order to build
an acceptable payout invoice was precisely the one the daemon misreported. A
client that trusted the info event got a cant-do back, and the order sat in
waiting-buyer-invoice until it was reaped.

The change

• Read the field each tag names — the fix itself.
• Extract the three ln_settings-derived tags into ln_policy_tags, mirroring
  the existing bond_policy_tags. The helper is spliced in at the original
  position, so the wire order of the info event's tags is unchanged.
• Document what separates the two windows on the settings fields themselves
  (src/config/types.rs), where the doc comments only paraphrased the names.

Why the extraction

Without it the regression test would be vacuous. test_settings() builds
LightningSettings::default(), which leaves both windows at 0, and
MOSTRO_CONFIG is a process-wide OnceLock no test can mutate — so a test
driven through info_to_tags() passes just as happily with the fields swapped.
Testing the pure helper allows pinning each window against a distinct value.
This is the same reason bond_policy_tags was split out, and its doc comment
says so.

Verification

The regression test was confirmed to fail against the original bug before the
fix was applied:

---- nip33::tests::ln_policy_tags_reports_each_window_from_its_own_field stdout ----
assertion `left == right` failed: invoice_expiration_window must report the buyer payout window
  left: Some("120")
 right: Some("600")

With the fix, the full suite is green:

test result: ok. 1234 passed; 0 failed; 2 ignored; 0 measured; 0 filtered out; finished in 16.44s

cargo clippy --all-targets --all-features -- -D warnings is clean and
cargo fmt has been applied. No schema or config changes: the tag name and the
settings keys are untouched, only the value the tag is filled from. Clients
pick up the corrected value on the next info event.

Summary by CodeRabbit

• Bug Fixes

  • Corrected Lightning policy information so buyer invoice expiration windows are reported separately from seller-paid hold invoice lifetimes.
  • Ensured hold-invoice, hold-CLTV, and invoice-expiration settings are each represented accurately.

• Documentation

  • Clarified the distinction between buyer payout invoice expiration and seller-paid hold invoice lifetime in Lightning settings documentation.

• Tests

  • Added coverage to verify the two expiration values remain independent.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 63fe49aa-1de1-4844-8df0-d3bede211bbe

📥 Commits

Reviewing files that changed from the base of the PR and between 848ee3b and 7d246be.

📒 Files selected for processing (2)

• src/config/types.rs
• src/nip33.rs

Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review.

---

Walkthrough

Changes

The Lightning info tags now report invoice_expiration_window from its dedicated setting. A helper builds the policy tags, and a regression test verifies distinct invoice and hold-invoice values.

Lightning policy tag correction

Layer / File(s)	Summary
Lightning policy tag construction src/config/types.rs, src/nip33.rs	The documentation distinguishes buyer payout invoice expiration from seller-paid hold-invoice lifetime. info_to_tags delegates Lightning policy tag creation to ln_policy_tags, which uses the corresponding settings fields.
Distinct expiration regression coverage src/nip33.rs	The test uses different invoice and hold-invoice windows and verifies both generated tags.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 7d246

This change corrects the advertised invoice expiration value while preserving tag names and ordering; no actionable merge-blocking risk remains after normal checks and review.

Suggested reviewers: grunch, arkanoider

Poem

A bunny checks each Lightning tag,
No copied window trails its lag.
Hold stays hold, invoices shine,
Two settings keep their values fine.
Tests hop neatly through the line.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the fix to advertise the correct invoice_expiration_window value.
Linked Issues check	✅ Passed	The changes use the correct setting, preserve tag order, add distinct-value regression coverage, and clarify related documentation [#895].
Out of Scope Changes check	✅ Passed	All changes support the linked issue by fixing tag construction, adding regression coverage, or clarifying related documentation.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 2 files.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Catrya]

The fix itself is right. Blocking on one doc comment this PR gets wrong.

hold_invoice_expiration_window: "Lifetime, in seconds, of the hold invoice
the seller pays" is false. After this PR nothing reads that setting except
the info tag itself: create_hold_invoice (src/lightning/mod.rs:150-156)
passes only cltv_expiry and leaves expiry at 0, so LND applies its
default of 86400s. The invoice lives 24h while we advertise 300s, the same
class of bug this PR is fixing on the sibling tag, now stated explicitly in a
doc comment instead of merely implied. Please document what's true and open a
follow-up for the real fix:

/// Advertised in the info event only, it is *not* applied to the hold
/// invoice, which is created without an `expiry` and so uses LND's
/// default (86400s). Distinct from `invoice_expiration_window`, which
/// governs the payout invoice. See #<follow-up>.

Two non-blocking notes while you're in there:

• invoice_expiration_window also gates bond payout invoices
  (src/app/bond/payout.rs:1391), and does not apply to LNURL /
  Lightning-address destinations (src/lightning/invoice.rs:56-59), so
  "a buyer payout invoice" is off in both directions.
• No test asserts info_to_tags still emits the block — drop the
  extend(ln_policy_tags(...)) line and the suite stays green.

[21Mill]

Closing as superseded by #952, which landed the same fix on 2026-09-04.

That PR corrects the tag the same way this one did and goes one better: invoice_window_tags is the equivalent of the helper extracted here, its test pins 3600/300 against distinct values for the same reason (the shared test settings leave both windows at 0, so the natural test passes with the bug present), and info_to_tags_emits_both_invoice_window_tags closes the gap @Catrya flagged in review — nothing here asserted info_to_tags still emitted the block, so deleting the call left the suite green.

Rebasing this onto main conflicts squarely with #952 in info_to_tags, and there is nothing left to salvage from the diff.

Two things this PR raised that #952 does not cover, so they do not get lost:

• @Catrya was right that the doc comment added here was false, and the underlying problem outlives it. It turned out to be wider than a wrong comment: hold_invoice_expiration_window has no reader at all, and the deadline its template entry describes is enforced by expiration_seconds under a different name and a different value. Filed as hold_invoice_expiration_window duplicates expiration_seconds and loses #955.
• Info event advertises hold_invoice_expiration_window under the invoice_expiration_window tag #895 is still open even though its bug is fixed — fix: info event advertised the hold window as invoice_expiration_window #952 did not link it. Worth closing.

Thanks for the review, @Catrya — the blocking point was correct and it is what led to #955.