ShapeStream keeps waiting out its backoff after the browser comes back online

未关闭
  • 哪里不对？
#4,832 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
72/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
playwright, typescript
领域
backend-api-design

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.ts says 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/client 1.5.28, through @tanstack/electric-db-collection 0.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.

主要语言
TypeScript
星标
10.4k
派生
399
30 天内没有已合并 PR

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

electric-sql/electric 的其他 Issue

查看 electric-sql/electric 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。