feat: advertise maintenance mode in the info event, republish on change (Phase 3) - #935
Conversation
…ge (Phase 3) - info_to_tags(ln_status, maintenance) always emits ["maintenance_mode", "true"|"false"] so clients can warn before mining PoW for a request that will be rejected (protocol book: MostroP2P/protocol#57). - MaintenanceState gains a Notify signalled after every successful set; changed() resolves on it (permit kept if nobody is waiting yet, nothing on a failed write). - job_info_event_send reads the flag each tick and waits on select!(interval, changed()) via a testable wait_for_info_wake helper, so a SetMaintenanceMode is visible to clients at once instead of after publish_mostro_info_interval. Spec: docs/MAINTENANCE_MODE_LN_MIGRATION.md §3.5 (#932). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0148ZQvcc8LfrsTYx9VAiSxS
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 137d617a1e
ℹ️ 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".
| if wait_for_info_wake(tokio::time::Duration::from_secs(interval), &maintenance).await | ||
| == InfoWake::MaintenanceChanged |
There was a problem hiding this comment.
When maintenance changes less than one second after the preceding info publication, this wake path creates the replacement through new_info_event, which uses second-precision Timestamp::now(). Both kind-38385 events can therefore have the same created_at; NIP-01 then selects the lower event ID rather than the later publication, so a relay may retain the old maintenance_mode value until the next interval. Use a per-info-event monotonic timestamp, as the dispute and order replacement paths already do.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 7202711: new_info_event now stamps created_at through a per-d-tag monotonic registry (monotonic_info_event_timestamp, same monotonic_created_at rule as orders and disputes) instead of passing None. Tests: registry bumps a same-second republish and lets wall clock win once ahead; two consecutive new_info_event calls yield strictly increasing created_at.
A maintenance-mode flip republishes the kind-38385 info event at once; if that lands in the same second as the previous publish both revisions tie on created_at and NIP-01 keeps the lower event id, possibly the stale maintenance_mode value. new_info_event now stamps created_at through the same monotonic registry the order and dispute events use, keyed by the info event's d tag. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0148ZQvcc8LfrsTYx9VAiSxS
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (4)
WalkthroughChangesThe PR adds change notifications to Maintenance-aware info events
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested reviewers: Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
1 participant
Summary
Phase 3 of the maintenance-mode / Lightning node migration spec (#932, §3.5): client signalling.
maintenance_modetag in the NIP-33 info event (info_to_tags(ln_status, maintenance)), always emitted as"true"/"false"likebond_enabled, so clients can tell "maintenance off" from "older daemon" and warn the user before mining PoW for anew-order/takethat will be rejected. Documented in the protocol book (docs: document maintenance mode (cant-do reason + info-event tag) protocol#57).MaintenanceStategains atokio::sync::Notifysignalled after every successfulset(changed()resolves on it; a permit is kept if nobody is waiting yet; a failed write signals nothing).job_info_event_sendreads the flag on every tick and waits onselect!(interval, changed()), factored intowait_for_info_wakeso the wake rule is unit-testable without a nostr client. Result: aSetMaintenanceModeis visible to clients right away instead of afterpublish_mostro_info_interval.Independent of Phase 2 apart from sharing
MaintenanceState; the RPC needs no change becausesetitself notifies.Test plan
info_to_tags_emits_maintenance_mode_false_by_default/_true_when_enabledset_wakes_a_changed_waiter_and_stores_a_permit— waiter registered before the change wakes; a change before the wait is still observed; a failedset(closed pool) does not signalinfo_wake_fires_on_maintenance_change_before_the_interval— 1 h interval, flag flips, helper returnsMaintenanceChangedwithin 1 sinfo_wake_falls_back_to_the_interval— paused clock, returnsIntervalcargo test: 1276 passed ·cargo clippy --all-targets --all-featuresclean ·cargo fmt --check🤖 Generated with Claude Code
https://claude.ai/code/session_0148ZQvcc8LfrsTYx9VAiSxS
Summary by CodeRabbit
New Features
Bug Fixes