sdk: retain reconnect requests across connection task teardown

[erskingardner]

Description

A reconnect requested after disconnect() can be lost while the previous connection task is still exiting, leaving the relay Pending without a running task. Subscription restoration also uses second-resolution timestamps, so two connections within one second can leave long-lived subscriptions inactive.

Serialize connection-task ownership and retain a reconnect request until the old task releases it. Reserve ownership before try_connect dials; cancellation releases that reservation, and a superseded dial cannot publish Connected. Clear stale termination permits before starting a replacement task. Track subscriptions by successful connection generation so immediate reconnect restores them reliably.

Notes to the reviewers

The public API signatures are unchanged. Disconnect/Terminated describe a termination request, not a task-exit barrier; the documentation now states this. Ban and shutdown cancel pending reconnects.

Deterministic teardown barriers exercise reconnect with automatic retries enabled and disabled, concurrent connect calls, stale termination permits, shutdown cancellation, and try_connect ownership conflicts. Additional regressions verify state changes while the admission policy is pending and release of connection ownership on dial cancellation or timeout. Loopback tests verify restored subscriptions and independent NIP-42 signers across reconnect.

Validation: just fmt and the complete just precommit passed locally on the pinned toolchain, including SDK tests with default and local-relay features, the configured WASM checks, Clippy, and documentation checks.

Checklist

• I followed the contribution guidelines
• I updated the relevant CHANGELOG.md (if applicable)
• I understand and can explain all code in this PR

[codecov]

Codecov Report

❌ Patch coverage is 97.41036% with 13 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
nostr-sdk/src/relay/inner.rs	97.23%	9 Missing ⚠️
nostr-sdk/src/relay/api/try_connect.rs	96.42%	4 Missing ⚠️

📢 Thoughts on this report? Let us know!

[erskingardner]

Can this one be closed now @yukibtc seems like it was incorporated in another PR?

[yukibtc]

Can this one be closed now @yukibtc seems like it was incorporated in another PR?

Yeah, but before closing this I'll wait that the other one will be merged.

[yukibtc]

@erskingardner, if you get the chance, could you give a try to #1491?

It should behave in the same way of this one. I've just rebased it on master branch, so includes also #1483

[erskingardner]

I'll have a look now.

[erskingardner]

Thanks @yukibtc. I tried #1491 (31a0237) against what #1479 was fixing, and it covers our cases:

• reconnect requested while the previous connection task is still exiting
• try_connect ownership: a superseded dial can't publish Connected, and cancelling or timing out a dial releases ownership
• ban/shutdown cancelling a pending reconnect
• same-second reconnect restoring subscriptions

try_connect now waits for the old connection to close instead of returning an error. That works fine for us.

I also ran two tests from #1479 against #1491. Both pass, and they could be worth bringing over since #1491 doesn't test either case:

• auth_gated_clients_keep_independent_signers_across_removal_and_reconnect: a loopback NIP-42 test that copies over unchanged.
• try_connect_rechecks_state_after_connection_policy: ban/shutdown while the admission policy check is still pending.

There's one issue we hit on #1491 (I haven't checked whether it was already on master): a REQ queued while the relay is disconnected gets sent twice after reconnect. This happens with a plain Relay::subscribe() too, not only send_msg. The reconnect restore sends the subscription, then the queued REQ goes out as well. A relay that rejects duplicate subscription ids answers CLOSED duplicate:, and the SDK then deregisters the subscription, so it's silently lost. Relatedly, update_subscription doesn't reset the subscription's EOSE flag or event counter when a REQ is re-sent. Happy to open a separate PR for this if you'd rather keep #1491 focused.

Closing #1479 once #1491 merges is fine with me.

For context, a few more fork changes are still keeping us off upstream, and I'll open separate PRs for them:

1. bounded, cancellable event acquisition (item/byte limits, fetched events kept out of live notifications and the seen-event DB)
2. Relay::batch_msg (atomic CLOSE+REQ) and a public per-subscription EOSE query, which we use to repair live subscriptions after notification lag

[erskingardner]

Quick follow-up on the duplicate REQ: I checked and it's already on master too, so it's not a regression from #1491 and doesn't need to block it.

Repro (loopback relay that answers a repeated subscription id with CLOSED duplicate:):

1. Subscribe live, let the connection drop.
2. While disconnected, either call relay.subscribe(..).with_id("live") again, or send_msg a CLOSE + REQ for it.
3. After reconnect the relay receives REQ live twice (the queued frame, then the reconnect restore), answers the second with CLOSED duplicate:, and the subscription is gone from the registry.

I'll open a small PR with the fix and this test. Want it based on sdk-rework-relay-task or on master?

[yukibtc]

I also ran two tests from #1479 against #1491. Both pass, and they could be worth bringing over since #1491 doesn't test either case:

• auth_gated_clients_keep_independent_signers_across_removal_and_reconnect: a loopback NIP-42 test that copies over unchanged.
• try_connect_rechecks_state_after_connection_policy: ban/shutdown while the admission policy check is still pending.

Thanks, added at #1491

I'll open a small PR with the fix and this test. Want it based on sdk-rework-relay-task or on master?

Thanks, I've just merged #1491 so it can be based on master.