Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#5,983 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
28/100
Loại issue
Lỗi
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
databases, distributed-systems, networking

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Rust
Star
25.2k
Fork
1.1k
Merge trung bình
3 ngày 17 giờ
Pull request đã merge (30 ngày)
45

Chuẩn bị môi trường

Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. Hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của clockworklabs/SpacetimeDB

Tất cả issue của clockworklabs/SpacetimeDB

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.