[erskingardner]

Description

When subscription verification is on (verify_subscriptions or ban_relay_on_mismatch), the SDK counts the stored events a subscription receives before EOSE if it has a single filter with a limit. Any event past the limit is rejected, and with ban_relay_on_mismatch the relay is banned.

Problem. When a subscription is restored after a reconnect, its REQ is sent again, so the relay starts a new stored-events query. update_subscription(.., true) kept the previous received_eose flag and received_events count, which causes two problems:

• The connection dropped before EOSE: the count continues from the previous session. A well-behaved relay that resends its stored events goes over the limit, its events are rejected, and with ban_relay_on_mismatch it is banned.
• EOSE had already been received: the limit check is skipped for the new query.

Fix. Reset both fields when the subscription is marked as subscribed again. This is the same reset that update_auto_closing_subscription already does for auto-closing subscriptions.

Notes to the reviewers

• Two new tests drive handle_event_msg directly, one for each direction. Both fail on master and pass with this change.
• This is the follow-up mentioned in sdk: avoid duplicate REQ for subscriptions queued while disconnected #1492, and it's independent of it. sdk: avoid duplicate REQ for subscriptions queued while disconnected #1492 adds a second place that records a queued REQ for a subscription (queue_msg). Whichever PR merges second should reset these fields there too. I'm happy to add that to whichever one is still open.

Checklist

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

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!