stackchain/stackchain-dashboard
1
0
Fork 0
Code Issues 9 Pull Requests 1 Actions Packages Projects Releases 713 Wiki Activity

Honor server backoff and section freshness in live polling #465

New Issue
Closed
opened 2026-08-10 08:09:41 +00:00 by timmy · 0 comments
timmy commented 2026-08-10 08:09:41 +00:00
Owner
Copy Link

Problem

The live dashboard poller retries every 8 seconds after both successful and failed requests. The backend already returns per-section freshness and retry_in_seconds, but the browser only displays this scheduling data. During a full upstream cooldown, every visible tab continues polling; during a partial outage, a blanket delay would also risk slowing healthy sections.

Vertical slice

  • Schedule from the earliest healthy section freshness deadline.
  • When all sections are degraded, honor the server cooldown.
  • Honor HTTP Retry-After and use bounded transport-failure backoff.
  • Keep reconnect, visibility restore, and explicit refresh immediate.
  • Document and behavior-test the scheduling contract.

Acceptance tests

  • A wholly degraded snapshot with retry_in_seconds: 60 waits 60 seconds.
  • A partial failure schedules at the earliest healthy section deadline.
  • HTTP 503 Retry-After controls the next attempt.
  • Consecutive transport failures back off to a cap and success resets the streak.
  • Explicit refresh/reconnect bypasses delayed retries without stale response overwrite.
  • Existing polling and full suites pass.

Non-duplication

Historical #131 pooled dashboard polling; #149 added server-side outage cooldown; #285 omitted unchanged payloads; #303 recovered stalled requests; #433 shared refreshes across workers. None makes the browser consume section freshness, cooldown, or Retry-After. No open issue or PR covers this behavior.

## Problem The live dashboard poller retries every 8 seconds after both successful and failed requests. The backend already returns per-section freshness and `retry_in_seconds`, but the browser only displays this scheduling data. During a full upstream cooldown, every visible tab continues polling; during a partial outage, a blanket delay would also risk slowing healthy sections. ## Vertical slice - Schedule from the earliest healthy section freshness deadline. - When all sections are degraded, honor the server cooldown. - Honor HTTP `Retry-After` and use bounded transport-failure backoff. - Keep reconnect, visibility restore, and explicit refresh immediate. - Document and behavior-test the scheduling contract. ## Acceptance tests - A wholly degraded snapshot with `retry_in_seconds: 60` waits 60 seconds. - A partial failure schedules at the earliest healthy section deadline. - HTTP `503 Retry-After` controls the next attempt. - Consecutive transport failures back off to a cap and success resets the streak. - Explicit refresh/reconnect bypasses delayed retries without stale response overwrite. - Existing polling and full suites pass. ## Non-duplication Historical #131 pooled dashboard polling; #149 added server-side outage cooldown; #285 omitted unchanged payloads; #303 recovered stalled requests; #433 shared refreshes across workers. None makes the browser consume section freshness, cooldown, or `Retry-After`. No open issue or PR covers this behavior.
timmy self-assigned this 2026-08-10 08:09:41 +00:00
timmy closed this issue 2026-08-10 08:19:38 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
P0

Drop everything

  
P1

High priority

  
P2

Medium priority

  
agent:nightprowl

Assignments routed to the LongCat NightProwl evaluation worker

  
backend

Backend service

  
ci

Continuous integration / actions

  
frontend

Frontend / UI

  
meta

Meta / planning

  
pages

Gitea Pages

  
template

Repo template / standards

No Label
P0
P1
P2
agent:nightprowl
backend
ci
frontend
meta
pages
template
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
timmy
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: stackchain/stackchain-dashboard#465
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?