Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Maincloud: subscription deliveries freeze 7–63 s under large fan-out (repro, 2.10.1)

Aperta
  • Qualcosa non va?
#5,983 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
28/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
databases, distributed-systems, networking

Direzione di ricerca

Start with the Maincloud database coinsteam-staging-stall-probe and reproduce the 230-subscriber set_beat workload described in the issue. Compare delivery gaps across the reported client vantages and review the available probe scripts and raw timings. Done means identifying whether Maincloud WebSocket ingress or host egress causes the stalls and documenting a confirmed mitigation or fan-out limit.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

On Maincloud, when one transaction's update fans out to 50–230 WebSocket subscribers at once (~10–90 MB in total), some connections stop receiving bytes for ~7.5 / 15 / 31 / 63 s after the reducer call has returned, then receive the rest in one burst. The gaps match TCP retransmission backoff, which suggests repeated packet loss somewhere on the Maincloud side (front end or host egress).

Why we think it is platform-side

  • It happened at the same moments, with the same worst cases, to clients on three independent vantages: two Linux hosts on one ISP, and Cloudflare Durable Objects using raw WebSockets (no SDK). Example: 45.1 / 45.0 / 45.0 s on the same transition.
  • A frozen connection receives 12–160 KB of the update, then zero bytes for 7.5, 15 or 30 s, then the remainder. The client event loop lagged ≤ 21 ms and the client kernel dropped nothing; bytes stop arriving before the client reads them.
  • Same behaviour with confirmed reads on and off.
  • Light traffic is clean: 28,440 small deliveries peaked at 438 ms. Once, 2 KB updates froze ~28 s about 2 minutes after a heavy run, so the effect seems to linger.

Minimal repro (SpacetimeDB 2.10.1, TypeScript module)

  • One public table beat { id: u32 (pk), n: u64, pad: string, at: timestamp }.
  • Reducer set_beat(n: u64, padLen: u32) overwrites row 1 with a pad of padLen bytes.
  • 230 subscribers to SELECT * FROM beat.
  • Call set_beat(n, 200000) every 8 s.
  • Result: last-subscriber lag up to ~61 s, and ~25 % of deliveries arrived more than 2.5 s late.

The repro database is coinsteam-staging-stall-probe on Maincloud; we can keep it up for you. Happy to share the probe scripts and raw timings.

Questions

  • Is there burst shaping or policing on Maincloud's WebSocket front end or host egress?
  • Is this a known issue, and is there a recommended limit on per-transaction fan-out bytes?

Why it matters to us: we rely on subscription updates to remove revoked data from users' screens within a bounded time. A frozen connection also delays those deletions.

Lingua principale
Rust
Stelle
25.2k
Fork
1.1k
Merge medio
3g 17h
PR unite (30g)
45

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di clockworklabs/SpacetimeDB

Tutte le issue di clockworklabs/SpacetimeDB

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.