ShapeStream keeps waiting out its backoff after the browser comes back online
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 72/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- playwright, typescript
- Lĩnh vực
- backend-api-design
Hướng nghiên cứu
Start by reading the backoff and abort handling in fetch.ts, then trace how ShapeStream manages retry waits and browser visibility events. Check the existing tests for those paths and add coverage for an online event interrupting a wait; confirm waiting streams retry promptly and still recover through the existing visibility and wake behavior.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
What happens
When a browser goes offline, each ShapeStream's requests fail, and each stream backs off on its own timer: 1 s, 2 s, 4 s and so on, up to 32 s, with full jitter. When the browser comes back online, nothing ends these waits. Each stream retries only when its own timer runs out. So data that changed on the server can take seconds to show, although the network and the backend are fine again.
The client already ends a wait early in two other cases:
- tab visibility: a hidden tab pauses the stream, and a visible tab resumes it with a catch-up request;
- wake from sleep, outside browsers: the comment in
fetch.tssays aborts "interrupt the backoff immediately (e.g. system wake reconnects)".
There is no listener for the browser's online event, so coming back online is the one case that waits.
Setup
@electric-sql/client1.5.28, through@tanstack/electric-db-collection0.5.9- default
backoffOptions - 11 shapes on one device, all through the same proxy, over HTTP/2
- Chromium, driven by Playwright
How we measured
We cut a device off for a few seconds by failing its requests in Playwright, then let them through and dispatched an online event on window. (This simulates offline by failing requests; it isn't a real network loss.) We timed when each shape got its first successful response afterwards.
What we saw
Most runs recovered in about 0.2 s. In 6 of 30 runs, the shapes came back one by one, over seconds. The slowest run:
| Request after reconnect | First success |
|---|---|
| our write endpoint, same server | 21 ms |
list_items |
410 ms |
settings |
756 ms |
recipe_tags |
969 ms |
tags |
1,789 ms |
category_corrections |
7,257 ms |
The backend answered after 21 ms. category_corrections still waited over 7 s, so a change synced through it showed 7 s late. After a longer offline period, the waits reach 16–32 s.
Expected
When the browser fires online, every stream that is waiting in backoff retries at once, as it already does after a wake from sleep.
Possible fix
In browsers, listen for online on window. On the event, end the current backoff wait and retry now, the same way the wake handling does. A small random delay, such as 0–500 ms, would keep all streams from retrying at the same instant.
Workaround we're trying
A custom runtimeVisibility adapter that reports hidden while the browser is offline and visible once it's back online, so the stream pauses and then resumes with a catch-up request. It works through a public option, but it replaces the built-in tab-visibility handling, so the adapter has to cover both.
Related
#3897 covers the other half: the backend recovers while the device stays online, and one stream's success should wake the others. The two fixes complement each other.
- Ngôn ngữ chính
- TypeScript
- Star
- 10.4k
- Fork
- 399
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của electric-sql/electric
-
camelToSnake and snakeCamelMapper() drop the underscore when a digit precedes a camelCase boundaryĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
electric-sql/electric#4855 ·
-
ShapeStream does not notify subscribers when it gives up on a non-Error valueCó thể đã có người làm @Tyagiquamar đã nhận 19 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
electric-sql/electric#4830 ·
-
@electric-sql/client throws SecurityError on import when the browser blocks site storage (typeof localStorage outside try)Có thể đã có người làm @mohanedmoh đã nhận 37 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
electric-sql/electric#4826 · 1 bình luận ·
-
agents-chat-starter: spawn PUT goes to the durable-streams proxy, so no entity is created and agents never wakeCó thể đã có người làm @adityavkk đã nhận 133 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
electric-sql/electric#4687 ·
-
Listen IP addressĐang mởfeature request triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
electric-sql/electric#4150 · 1 bình luận ·
Tất cả issue của electric-sql/electric
Issue tương tự
-
Bug: Broken RTL / BiDi text rendering when mixing Persian (Farsi) with English or numbersCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởbug
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 68/100
amosblomqvist/learnharness#758 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Change WorkspacesĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
bitfocus/companion-module-renewedvision-propresenter-api#134 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
rcpch/digital-growth-charts-react-component-library#304 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
dsh-market/dsh-market#1210 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
trustjonathan/STUDY-HUB#13 ·