SSR deadlocks when 2+ Suspense/Transition boundaries share 2+ Resources via `.get()`

[alilee]

Describe the bug

When two or more Suspense/Transition boundaries read the same two or more Resources using the reactive .get() pattern, SSR streaming deadlocks with certain Tokio worker_threads counts. The initial HTML with fallbacks is sent but the resolved <template> chunks are never flushed. The response hangs until timeout.

The workaround {move || Suspend::new(async move { r.await })} (awaiting Resources as Futures inside Suspend::new) resolves correctly in all configurations.

Leptos Dependencies

leptos = { version = "0.8.15" }
leptos_router = { version = "0.8" }
leptos_axum = { version = "0.8", optional = true }
axum = { version = "0.8", optional = true }
tokio = { version = "1", features = ["rt-multi-thread", "macros", "net"], optional = true }

To Reproduce

cargo run --features ssr

Then in another terminal:

# This deadlocks — Suspense boundaries never resolve:
curl -s -m 5 http://localhost:3000/broken | grep -c 'RESOLVED_RESOURCES'
# Output: 0 (curl times out, no resolved resources in response)

# This works — all boundaries resolve immediately:
curl -s -m 5 http://localhost:3000/works | grep -c 'RESOLVED_RESOURCES'
# Output: 1

Next Steps

• I will make a PR
• I would like to make a PR, but need help getting started
• I want someone else to take the time to fix this
• This is a low priority for me and is just shared for your information

Additional context

This is a deadlock in the SSR streaming renderer, not a race condition. The threading dependency pattern suggests two Suspense boundaries' reactive subscriptions create a circular wait when their tasks are distributed across 2-3 Tokio worker threads:

• With 1 thread (or current_thread): all tasks run cooperatively on one thread, so no cross-thread contention is possible — tasks are polled round-robin and all complete.
• With 2-3 threads: tasks from the two boundaries get distributed across threads and create a circular dependency — each thread holds a resource that the other needs, causing a classic deadlock.
• With 4+ threads: enough worker threads are available that the scheduler can make progress despite the contention — the circular dependency doesn't form.

The Suspend::new(async move { r.await }) workaround serializes Resource access within each boundary (sequential awaits within a single async block), breaking the circular dependency that causes the deadlock.

On AWS Lambda (128MB default, 2 visible cores), this manifested as intermittent 500 errors (~40-60% failure rate) rather than a consistent deadlock, likely because Lambda's heavy CPU throttling (~0.07 vCPU) introduces timing variability that sometimes breaks the deadlock. Locally with worker_threads = 2 and full CPU, it deadlocks 100% of the time.

Files

ISSUE.md
Cargo.toml
main.rs

[gbj]

I have not yet tried to reproduce the issue, only read the code, but this catches my eye:

let a = r_a.get()?.ok()?;
let b = r_b.get()?.ok()?;

Does this behave differently if you avoid short-circuiting?
i.e., something like

let (a, b) = (r_a.get(), r_b.get());
let a = a?.ok()?;
let b = b?.ok()?;

As written, this will never try to read from b until a has completed loading, because it bails out if a is None. This means that the Suspense does not initially think it needs b, but then later discovers it. Whereas if you read from them both at first, before the early return with ?, it will know it needs both of them from the beginning.

[alilee]

I follow the thinking, but the same result unfortunately.

ISSUE.md
main.rs

[alilee]

Analysis

Update: Testing confirms this is a livelock (infinite CPU-bound loop), not a classical deadlock. The /hyp2 route's invocation counters show ~297,000 closure invocations per boundary within a 5-second timeout, consuming 100% CPU without making progress.

Possible root cause

The Suspense Effect's dry_resolve mechanism creates an infinite re-registration cycle:

1. Suspense Effect sees tasks.is_empty() → calls children.dry_resolve()
2. dry_resolve re-runs the reactive closure → calls .get() on each Resource → creates new TaskHandles + spawns monitor tasks (even though Resources are already resolved)
3. Monitors complete in one poll cycle (Resources are ready) → each drops its TaskHandle → mark_dirty() on the Effect
4. With 2-3 threads, Tokio's LIFO slot optimization causes the Effect to be scheduled between individual monitor completions → Effect sees partially-drained tasks → resets double_checking to false
5. Eventually all monitors complete → Effect sees tasks.is_empty() again → back to step 1

This explains the thread-count dependency:

• With 1 thread (or current_thread): cooperative scheduling means all monitors complete before the Effect runs (FIFO ordering), so the Effect sees all tasks drained atomically.
• With 2-3 threads: Tokio's LIFO slot scheduling interleaves the Effect with monitor completions. The Effect is woken by each monitor dropping a TaskHandle, sees the remaining monitors as pending, resets its state machine, and eventually triggers another dry_resolve.
• With 4+ threads: enough parallelism that all monitors complete on separate threads before the Effect processes any of their notifications.

The Suspend::new(async move { r.await }) workaround avoids this entirely because it creates no TaskHandles — the SuspenseContext's task SlotMap stays empty, and the Effect immediately signals completion.

[alilee]

Working on a patch

[alilee]

#4579