[Bug]: Large workspace causes permanent server reconnect loop when a remote client subscribes
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 38/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- macos
- 領域
- backend, networking
調査の方向性
Issue にはソースファイルやテストの指定がありません。まずサーバーの workspace サブスクリプションの経路と relay の状態転送を追跡し、次に、socket の動作と logging を確認しながら、説明されている大きい workspace と小さい workspace で再現します。完了条件は、大量の履歴を持つサブスクリプションが接続されたままになること、または pagination や lazy loading が実装されていない場合に、失敗が明確に記録されることです。
索引モデルが issue の本文から書いたものです。
説明
Platform
macOS
Operating system version
macOS Tahoe 26.5.2 (25F84)
System architecture
ARM64 (M1, M2, etc)
PolyScope Version
0.24.1
Bug description
On a Mac mini running as an always-on server, one specific workspace makes the
server's relay connection collapse into a permanent reconnect loop as soon as a
remote client subscribes to it. Other workspaces on the same server are fine.
It happens both from the desktop app and from the mobile web client.
The workspace that fails has a far larger history:
| Workspace | messages | MB (messages.content) |
sessions |
|---|---|---|---|
| workspace-a | 15,363 | 40.3 | 40 |
| workspace-b | 262 | 0.6 | 3 |
| workspace-c | 0 | – | 0 |
workspace-a alone is 40.3 MB of a 48 MB polyscope.db, and 40.3 of the
41.1 MB of message content stored in the whole database.
It is not one oversized payload: the largest single message is 110 KB and the
mean is 2.7 KB. messages.metadata is negligible too (0.7 MB across the entire
database), so those figures account for essentially all of the stored state.
It looks like the cumulative volume pushed to the client on subscribe.
Nothing is logged on either machine. The only lines in main.log are
[updater] No update available.
Context: workspace-a had a long-running Autopilot goal going for two days.
When the Claude session limit is hit the SDK fires a burst of retries
(~23 messages), each opening a session — hence 40 sessions. So the history
inflates over time and the problem gets progressively worse.
Steps to reproduce
- Have a server with one large-history workspace and one small one.
- From a remote client on a different network (desktop app or mobile web), open
the large workspace. - On the server, watch the outbound relay socket:
lsof -nP -iTCP -sTCP:ESTABLISHED | grep -i polyscope | grep -v 127.0.0.1 - Switch the client to the small workspace and watch again.
Observed
With a client subscribed to the large workspace, the server's relay socket never
survives ~5 s — new fd, new source port, new handle on every sample, with gaps
where no connection exists at all. Reconnect bursts fire three simultaneous SYNs
to the three getpolyscope.com Cloudflare addresses every 8–12 s.
tcpdump shows each attempt completing the TLS handshake, transferring roughly
50–85 KB, then closing — consistent with a state transfer that never finishes.
Switching the client to the small workspace stabilises the socket immediately:
same handle and source port held for minutes. Switching back breaks it again
within seconds. Reproduced several times in both directions.
Reproduced from the desktop app and from the mobile web client.
The server process itself is healthy throughout: 3 d 06 h uptime, no crash
reports, 1.1 GB of 24 GB RAM, zero swap.
Expected
A workspace with a long history should stay reachable remotely — ideally by
paginating or lazily loading history instead of pushing the whole thing on
subscribe. At minimum the failure should be logged instead of surfacing as an
intermittent "Disconnected" with nothing in main.log.
Ruled out
- Process health: uptime, memory and swap all normal (above).
- macOS App Nap and power management (
pmsetfully configured for always-on). - Network topology / double NAT.
- Tailscale: identical behaviour with it disconnected, and
tcpdumpshows relay
traffic leaving via the LAN address straight to Cloudflare, never via100.x. - Duplicated server identity:
serverIdandserverIdentityin
~/.polyscope/settings.jsondiffer between the two machines. - Oversized individual message or metadata: max 110 KB, mean 2.7 KB, metadata
0.7 MB total. - Client-specific issue: reproduced from two different clients.
Relevant log output
- 主要言語
- 言語のデータがありません
- スター
- 20
- フォーク
- 0
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
beyondcode/polyscope-community のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 52/100
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
beyondcode/polyscope-community#189 · コメント 1 件 · リアクション 2 件 ·
beyondcode/polyscope-community の issue をすべて見る
似ている issue
-
Change output crossing a compactsize boundary leaves the fee slightly below the requested feerateオープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
bitcoindevkit/bdk_wallet#578 ·
メンテナーはふだん 8 日以内に返信
-
Hydraulic gas_pressure omits the reference-density offset, breaking roundtrips and the pressure joinオープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
ethereum/execution-apis#915 ·
メンテナーはふだん 1 日以内に返信
-
enhancement via-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
pingdotgg/t3code#14816 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
OpenConext/OpenConext-access#1015 ·
メンテナーはふだん 1 日以内に返信