Fix SSR Suspense livelock when multiple boundaries share Resources via .get()

[alilee]

Summary

One-line fix for an SSR livelock where 2+ Suspense/Transition boundaries sharing 2+ Resources via .get() causes the Suspense Effect to endlessly re-run dry_resolve(), consuming 100% CPU (~297k closure invocations per boundary per 5s) and never completing SSR.

Manifests on AWS Lambda (128MB, 2 cores → worker_threads=2) as intermittent 500 errors.

Root Cause

The Effect's isomorphic closure returns a bool that becomes double_checking: Option<bool>. After dry_resolve() returns true (setting double_checking = Some(true)), the Effect is woken by individual monitor completions. If tasks aren't empty yet, the catch-all false at the end resets double_checking to Some(false). When tasks finally drain, the Effect sees double_checking == Some(false) and calls dry_resolve() again — infinite cycle.

dry_resolve → true → double_checking = Some(true)
  monitor1 completes → Effect wakes → tasks NOT empty → returns false (RESETS!)
  monitor2 completes → Effect wakes → tasks empty + double_checking == Some(false) → dry_resolve again!

The Fix

leptos/src/suspense_component.rs, line 409:

-                false
+                double_checking.unwrap_or(false)

This preserves Some(true) through intermediate wakeups so the completion branch is reached:

dry_resolve → true → double_checking = Some(true)
  monitor1 completes → Effect wakes → tasks NOT empty → returns true (PRESERVED!)
  monitor2 completes → Effect wakes → tasks empty + double_checking == Some(true) → COMPLETION

Only the Some(true) → non-empty-tasks path changes behavior. All other paths return the same value as before.

Reproduction

Minimal repro at https://github.com/alilee/feedback/tree/main/bugs/ssr-race (Cargo.toml + src/main.rs).

cargo run --features ssr  # uses worker_threads = 2
curl -s -m 5 http://localhost:3000/broken | grep -c RESOLVED_RESOURCES  # 0 (livelock)
curl -s -m 5 http://localhost:3000/works  | grep -c RESOLVED_RESOURCES  # 1 (Suspend::new workaround)

Thread count dependency:

worker_threads	Result
1	Works
2-3	Livelocks
4+	Works

Testing

• New regression test: leptos/tests/ssr_suspense_livelock.rs — 2 Suspense boundaries, 2 shared Resources, worker_threads=2, 2s timeout
• All existing leptos crate tests pass (72 tests: 58 doc + 11 ssr + 2 pr_4061 + 1 new)
• Test fails without the fix, passes with it

[alilee]

I've tried to run the regression test suite, but I'm not familiar with the ci so I'm not confident I've fully leveraged the available testing - apologies in advance. Happy to do more work as you direct.

I think you might want to get ready for an avalanche of Claude Code originated PR's and set ultra-convenient standards for yourself, and maybe even provide prompts or agent commands to do what you need so that you can sit on the top - surgeon to all us nurses. You should feel completely justified in asking for people to invest their tokens on tasks! I really hope the shift is net beneficial for you and leptos.

[gbj]

I'm having trouble reproducing the bug, either against the main branch with the reproduction you provided in the issue or in the PR branch by reverting the change and running the test. The alilee/feedback repo linked in this PR appears to be private (or at least it 404s for me). Could you share that with me, and I'll see if I can reproduce it given that?

[gbj]

Ah ok, interesting. I am able to reproduce it against the latest published version, but not again git main. Could you confirm whether the bug occurs against the current state of the main branch? I am about to publish a new set of patch releases in any case.