[Bug] Workspace resource reads retry stale runner 503s for minutes

[Leemoonsoo]

Description

Workspace file hooks use the same 12-attempt retry budget for every runner_unavailable 503. When runner health is stale-online, or an older session still has unknown liveness, these background GETs cannot reconnect the runner and amplify one panel refresh into repeated requests over roughly two minutes.

Expected: retry only while the runner is plausibly starting (initial cold boot, snapshot load race, or an active-turn relaunch). Otherwise make one request. Tolerant search and inline-path existence reads should degrade to empty results without retrying.

Steps to reproduce

This is an intermittent liveness/routing race.

1. Open a session whose resource route returns 503 runner_unavailable while the runner-health snapshot still reports online or unresolved.
2. Open or refresh the workspace Files panel, or render inline file references.
3. Observe repeated /resources/environments/default requests with exponential backoff for about two minutes.

A stale or offline runner should receive one request per user trigger; a genuinely starting runner should retain the cold-boot retry budget.

Version

main at 405bbb7

OS

No response

Harness

No response

Harness mode

No response

Platform or device

No response

Observed impact

None

Authentication type

No response

[github-actions]

🤖 Automated triage

• Bot assessment: Medium impact
• Priority: P2-medium
• Why: Workspace file and inline-reference reads can issue repeated stale-runner requests for about two minutes, degrading session resource browsing but not blocking core session work; users can avoid repeated panel refreshes while the retry behavior is corrected.

This automated assessment uses the issue content and repository signals. Maintainers can override the priority label.