From e135265c8a8d7c9de5cb47056236cc6d0176c593 Mon Sep 17 00:00:00 2001 From: David Susskind Date: Mon, 31 Aug 2026 14:02:32 +0300 Subject: [PATCH] docs(base44-troubleshooter): name both causes of the polling fallback The raw-SSE aside said the CLI falls back to polling when the first connection is "refused", which is one of two causes. A first connect that keeps failing transiently exhausts its retries and polls too. The two-modes section above it already documents both, so the aside contradicted its own page. Caught in review of #157 after it merged. --- skills/base44-troubleshooter/references/project-logs.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/skills/base44-troubleshooter/references/project-logs.md b/skills/base44-troubleshooter/references/project-logs.md index aa5b42c..8860eed 100644 --- a/skills/base44-troubleshooter/references/project-logs.md +++ b/skills/base44-troubleshooter/references/project-logs.md @@ -162,7 +162,8 @@ The CLI handles all of this for you — this section matters only if you are con `false` is your choice as a raw consumer — the bounded polling route is the obvious one — but note the CLI itself does **not** do that: it ends the run with an error (see above). (And a fallback to polling in the CLI is driven by the *first* - connection being refused, never by an end frame.) + connection failing — either refused outright, or still unreachable after its + retries — never by an end frame.) - Reconnect on a drop rather than giving up on the first one. Carry the last seen timestamp across the reconnect — but for **dedupe**, and to resume a polling fallback where the stream left off. It does not make the handover gapless: a tail