[Bug] networkMonitor emits connectionRestored before new requests can succeed — race condition

[RUKAYAT-CODER]

Overview

src/services/networkMonitor.ts emits 'connectionRestored' event immediately when NetInfo reports isConnected: true. Subscribers (including requestQueue) immediately start replaying queued requests. However, the network stack may take 1-3 seconds after the isConnected event before DNS resolution and TCP connections succeed. The first replayed requests fail, are re-queued, and the retry logic starts from scratch.

Specifications

Features:

• After isConnected becomes true, perform a lightweight connectivity probe before emitting connectionRestored
• Probe: single HEAD request to /api/health with 5-second timeout
• If probe succeeds: emit connectionRestored
• If probe fails: wait 2 seconds and retry probe (max 5 probes before giving up)
• Total delay: typically < 2 seconds, max 12 seconds before declaring restored

Tasks:

• Add probeConnectivity(): Promise<boolean> in networkMonitor.ts
• Modify NetInfo isConnected handler to call probe before event emit
• Expose isProbingConnectivity state for UI indicators
• Add unit tests for probe success, failure, and timeout scenarios

Impacted Files:

• src/services/networkMonitor.ts

Acceptance Criteria

• connectionRestored event fires only after successful connectivity probe
• Queue replay does not trigger until connectionRestored fires
• Probe timeout is 5 seconds maximum
• Unit test confirms event not emitted on probe failure

[KingDavid9999]

@KingDavid9999 has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Hi maintainer, I'd very much appreciate the opportunity to work on this issue.
Having reviewed the acceptance criteria, I'm confident that I'd be able to have a PR up shortly after being assigned.
Kindly assign this issue to me.
Thank you!

ℹ️ Repo Maintainers: To accept this application, review their application or assign @KingDavid9999 to this issue.

[olufunsoolutayo]

@olufunsoolutayo has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Hello Maintainer. I'm begging 🥺. Please assign me this task. I'll resolve quickly. Thank you

ℹ️ Repo Maintainers: To accept this application, review their application or assign @olufunsoolutayo to this issue.

[abdulrcrtw]

@abdulrcrtw has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

I'd like to contribute here.

My approach: emits event immediately when reports . Subscribers (including ) immediately start replaying queued requests. However, the network stack may take 1-3 seconds after the event before DNS resolution and TCP connections succeed. The first replayed requests fail, are re-queued, and the retry logic starts from scratch. After becomes , perform a lightweight connectivity probe before emitting Probe: single HEAD request to with 5-second timeout

I'll add tests and documentation as part of the PR.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @abdulrcrtw to this issue.

[drips-wave]

Congratulations, @abdulrcrtw! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 30, 2026.

🧑‍💻 @abdulrcrtw: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊