You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Estimate waiting room wait as 1 minute per spot ahead
Decouples the user-facing wait estimate from the admission tick rate.
The estimate is now a rough one-minute-per-spot rule of thumb, which
reads more intuitively in the CLI than a tick-derived number that
shifts with deployment cadence.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: docs/freebuff-waiting-room.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -246,16 +246,16 @@ This is a **trust-the-client** design: the server still admits requests during t
246
246
247
247
## Estimated Wait Time
248
248
249
-
Computed in `session-view.ts`from the drip-admission rate:
249
+
Computed in `session-view.ts`as a rough one-minute-per-spot-ahead estimate:
250
250
251
251
```
252
-
waitMs = (position - 1) * admissionTickMs
252
+
waitMs = (position - 1) * 60_000
253
253
```
254
254
255
255
- Position 1 → 0 (next tick admits you)
256
-
- Position 2 → one tick, and so on.
256
+
- Position 2 → one minute, and so on.
257
257
258
-
This estimate **ignores health-gated pauses**: during a Fireworks incident admission halts entirely, so the actual wait can be longer. We choose to under-report here because showing "unknown" / "indefinite" is worse UX for the common case where the deployment is healthy.
258
+
This estimate is intentionally decoupled from the admission tick — it's a human-friendly rule-of-thumb for the UI, not a precise projection. Actual wait depends on admission-tick cadence and health-gated pauses (during a Fireworks incident admission halts entirely), so the real wait can be longer or shorter.
0 commit comments