ocr+runpod: a hardcoded "why", and growth that rented beside its own pod (v0.3.60)
Two reports from the Digesta side, both of which my own code caused.
**"resumption is disabled server-side (ocr.surya_max_continuations = 0)".** It
is not, and never was. Both config files leave the key unset, the dataclass
default is 8, and the running process resolves 8 for either candidate config
dir — checked inside the container through the app's own loader. The number came
from this, in ocr_worker:
elif capped and not resumed:
info["why"] = (f"the reply stopped at the {cap}-token cap and "
f"resumption is off (ocr.surya_max_continuations = 0) …")
a hardcoded string in a branch that is reached four different ways: budget zero,
a generation already repeating itself, no room left in the context window, or a
reply that could not be resumed at all. It asserted a configuration value it
never read, and it was believed — twice — and acted on. A diagnostic that names
the wrong cause is worse than one that says nothing.
So the reason is now recorded where it is known (`_no_resume`) and reported as
itself. The budget actually in force goes into `model_attempts` as
`max_continuations`, because printing the cap but not the budget is why a caller
could not tell a request that landed from one that was ignored. The old message
survives for the one case where it was true, and says it is about this page
rather than the server.
**Growth rented a card beside a pod it already owned.** Adoption was attempted
in three places — `ensure_ready`, `acquire` with nothing healthy, and the warm
floor — and the growth path was not one of them. Live at 23:10: a run adopted
one surviving pod, grew by one, and rented an RTX A6000 (after walking thirty
candidates) while a second healthy pod of its own sat idle in the registry,
billing for nothing until the reaper's grace would have expired.
`_grow_in_background` now adopts first, and a source-anchored test pins all
five provisioning sites so a sixth cannot quietly forget. `seed_region` stays
excluded by design: it exists to boot a pod in a NAMED region, and adopting one
elsewhere would not fill that region's volume.
tests/test_pool_growth_adopts.py (4), four more in
tests/test_surya_thread_boundary.py, one in tests/test_runpod_scale_out.py —
whose pool fake now stubs adoption, since left real it reads this machine's own
registry.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PxYHWbCAjjjD7A1rhFKtaW
Showing
Please
register
or
sign in
to comment