Panic in ws_encode_task: "buffer should be unique" (subscribe.rs)

[jacobjenks]

Summary

spacetimedb-standalone 2.1.0 panics in the websocket encode task with buffer should be unique and exits with status 1. systemd restarts the service; the panic recurs. We've seen 37+ restarts in a 24-hour window on a self-hosted production instance.

Stack trace

thread 'tokio-runtime-worker' panicked at
/home/runner/work/SpacetimeDB/SpacetimeDB/crates/client-api/src/routes/subscribe.rs:1366:48:
buffer should be unique
stack backtrace:
0: __rustc::rust_begin_unwind
1: core::panicking::panic_fmt
2: core::option::expect_failed
3: <scopeguard::ScopeGuard<T,F,S> as core::ops::drop::Drop>::drop
4: spacetimedb_client_api::routes::subscribe::ws_encode_task::{{closure}}
5: tokio::runtime::task::core::Core<T,S>::poll
6: tokio::runtime::task::harness::Harness<T,S>::poll
7: tokio::runtime::scheduler::multi_thread::worker::Context::run_task
8: tokio::runtime::scheduler::multi_thread::worker::Context::run
9: tokio::runtime::context::scoped::Scoped::set
10: tokio::runtime::context::runtime::enter_runtime
11: tokio::runtime::scheduler::multi_thread::worker::run
12: <tokio::runtime::blocking::task::BlockingTask as core::future::future::Future>::poll
13: tokio::runtime::task::core::Core<T,S>::poll
14: tokio::runtime::task::harness::Harness<T,S>::poll
15: tokio::runtime::blocking::pool::Inner::run
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.

Environment

• Version: spacetimedb-standalone 2.1.0, single-replica self-host
• OS: Ubuntu on a DigitalOcean droplet (4-core, 4 GB RAM)
• Frontend: Caddy reverse proxy → 127.0.0.1:3000 over WebSocket
• Module: ~34k LOC Rust WASM, scheduled 20 TPS tick reducer, ~30 public tables
• Concurrent clients: typically 3–10, occasional spikes to 20+

Observations

• Crash frequency scales with traffic. Under low load (1–2 clients) crashes are rare; under a recent traffic spike (~150 new
  client identities in 24 h), we hit 37+ crashes in the same window.
• Each instance runs ~7 minutes of CPU time before panicking and being restarted by systemd.
• Disk usage is at 26%; memory peaks at 1.3 GB; no OOM events in dmesg.
• The journal entries immediately before each panic show a flurry of websocket aborts (Connection reset without closing
  handshake) followed by reconnects.
• Service is running with RUST_BACKTRACE=1; happy to provide a full backtrace from the next crash if helpful.