the growth line named a trigger that had not fired (v0.3.100)
A pool with one healthy pod rented a second one second after the first became
ready, and said:
'datalab-to/surya-ocr-2': growing to meet 1 pod(s) of demand — 1 up, 1 booting
It needs one pod. It has one pod. It is renting another. Read plainly that is a
double-rent bug, and it took a real investigation to establish that the fleet
was behaving exactly as configured.
`_should_grow` has two independent triggers:
DEMAND (in-flight + waiting) / scale_up_inflight_per_pod, rounded up —
a measured number, and the one that may rent several at once.
SATURATION every serving pod is at its in-flight threshold, so the NEXT
request has nowhere good to go. Anticipatory, single-flight.
What happened was saturation: 16 pages landed on the one pod the moment it went
ready, 16 at a threshold of 16 is exactly one pod's worth, so demand was already
MET and that branch did not fire at all. But the caller computed
`_pods_for_demand()` itself, after the fact, and printed it whichever branch had
answered — so the line always claimed demand, and in the saturation case
reported a number that contradicted the action it was describing.
The decision now carries its own reason. `_grow_reason()` returns the sentence
of the trigger that fired ('' for no), `_should_grow` is `bool()` of it — the
bool contract is unchanged, callers and tests compare with `is True` — and
acquire() prints what it was given instead of recomputing a figure of its own.
Saturation now says so, and says what it is NOT:
growing — every pod is at its 16-in-flight threshold (least loaded carries
16) — renting one more for the next burst, not for work already queued
[1 up, 1 booting]
Nothing about when a pod is rented changes; only what the log says about why.
10 tests, including the live line as a regression: a saturation rent must not
contain the word "demand". Suite: 3142 passed, the same 13 known-stale failures.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM
Showing
Please
register
or
sign in
to comment