syntaqxRetrying a read that gets no answer never becomes a loop (after 71274eeb): a refresh of the page already showing kept trying every 5 s for as long as it took, which is right while the browser is offline but not on a network that is up and never answers (an extension or proxy blocking g1t's .data requests, a security policy, broken DNS): the page sat on old data under "Can't reach g1t" forever and never showed what was wrong, and a tab out of view kept asking too. Now a refresh counts only the time it waited while the browser said it was online, and gives up after 2 minutes of that (REFRESH_PATIENCE_MS); offline still waits as long as it lasts. Nothing is retried from a tab out of view: a wait that is over holds until the tab is looked at. While the error page tries on its own (lib/reconnect.ts, 3 s, 6 s, 12 s, then every 30 s), reads are tried once each instead of retrying underneath it, so a broken network costs one request every 30 s on a visible error page and none on a hidden one. A real error (an answer that is an error) was already never retried and stops the error page's trying. keepTrying in lib/resilient-fetch.ts makes the call. Checked: apps/web tsc -b; npm test (985; new: offline waited out however long, up-and-silent gives up for a refresh and a click, one try while the error page tries).992effdHistory
- ..
- 0001_init.sql
- 0002_reusable_workflows.sql
- 0003_settings_access.sql
- 0004_self_hosted_runners.sql
- 0005_actions_cache.sql
- 0006_artifacts.sql
- 0007_run_protection.sql
- 0008_actions_access.sql
- 0009_run_attempts.sql
- 0010_jobs_self_hosted_lower.sql
- 0011_schedule_rules.sql
- 0012_runner_task_runs.sql
- 0013_action_registry.sql
- 0014_managed_workflows.sql
- 0015_runner_isolation.sql
- 0016_log_chunks.sql
- 0017_workspace_managed_workflows.sql
- 0018_desktop_runners.sql
- 0019_brokered_secrets.sql
- 0020_job_token_rotation.sql
- 0021_log_retention.sql
- 0022_runner_machine.sql
- 0023_actions_enabled.sql