Fix #202 slow-network invite timeout handling #207

2026-04-15T17:11:13Z

priyanshu_bharti commented

2026-04-15 17:11:13 +00:00

Fix #202: Slow networks break invite codes

Problem

On slow or unstable networks, creating an invite could time out before receiving a claim code.

The invite claim request used a short timeout and did not reliably guarantee state cleanup when the request path stalled. This could leave users stuck on a loading spinner.

What changed

Updated src/app/components/SpaceInvite.svelte

Wrapped invite claim request flow in try/catch
Added finally block to always reset loading state
Increased request timeout to 10 seconds
Added an explicit timeout race guard so the flow fails fast even if abort signaling does not settle the request
Preserved graceful fallback to claimless invite links by setting claim to an empty string on failure

Behavior after fix

Invite creation no longer gets stuck on an infinite spinner on slow/offline conditions
If claim fetch fails or times out, users still get a usable invite link (claimless fallback)

Manual verification

Open app locally and navigate to Create Invite
Throttle network to a very slow profile
Open Create Invite modal
Confirm spinner stops and invite link appears after timeout window
Switch network to Offline and repeat
Confirm fallback still renders and spinner does not hang

Scope

Single-file change
No API contract changes
No UI design changes

# Fix #202: Slow networks break invite codes ## Problem On slow or unstable networks, creating an invite could time out before receiving a claim code. The invite claim request used a short timeout and did not reliably guarantee state cleanup when the request path stalled. This could leave users stuck on a loading spinner. ## What changed Updated [src/app/components/SpaceInvite.svelte](src/app/components/SpaceInvite.svelte) - Wrapped invite claim request flow in try/catch - Added finally block to always reset loading state - Increased request timeout to 10 seconds - Added an explicit timeout race guard so the flow fails fast even if abort signaling does not settle the request - Preserved graceful fallback to claimless invite links by setting claim to an empty string on failure ## Behavior after fix - Invite creation no longer gets stuck on an infinite spinner on slow/offline conditions - If claim fetch fails or times out, users still get a usable invite link (claimless fallback) ## Manual verification 1. Open app locally and navigate to Create Invite 2. Throttle network to a very slow profile 3. Open Create Invite modal 4. Confirm spinner stops and invite link appears after timeout window 5. Switch network to Offline and repeat 6. Confirm fallback still renders and spinner does not hang ## Scope - Single-file change - No API contract changes - No UI design changes

priyanshu_bharti commented

2026-04-15 17:18:07 +00:00

Hi @hodlbod,
I’ve fixed Issue #202 (Slow networks break invite codes).
I properly tested it with heavy network throttling (Slow 3G + custom high latency).
Added try/catch + finally block in SpaceInvite.svelte, increased timeout to 10 seconds, and ensured graceful fallback on error/timeout.
The infinite spinner issue is now resolved.
PR is ready for review.
Thanks!

Hi @hodlbod, I’ve fixed Issue #202 (Slow networks break invite codes). I properly tested it with heavy network throttling (Slow 3G + custom high latency). Added try/catch + finally block in SpaceInvite.svelte, increased timeout to 10 seconds, and ensured graceful fallback on error/timeout. The infinite spinner issue is now resolved. PR is ready for review. Thanks!

hodlbod reviewed 2026-04-15 21:00:18 +00:00

src/app/components/SpaceInvite.svelte Outdated

						
				@@ -53,0 +49,4 @@

				          }),

				          sleep(10000).then(() => {

				            throw new Error("Invite claim timed out")

				          }),

hodlbod commented

2026-04-15 21:00:16 +00:00

Do we need this? The timeout signal should abort the request with no events, which means the claim would be set to an empty string in any case. I think this is over-complicating it and increasing the timeout to 10s would be sufficient

priyanshu_bharti commented

2026-04-15 22:00:56 +00:00