fix: set explicit workerName matching the manifest name in worker templates#39
fix: set explicit workerName matching the manifest name in worker templates#39sergiofilhowz wants to merge 1 commit into
Conversation
…plates Since iii 0.21.5 (iii-hq/iii#1949, MOT-3931), `iii worker add --wait`, `iii worker status`, and `iii worker list` trust only the names reported by `engine::workers::list`. Workers that never set a name fall back to the SDK's `hostname:pid` default ("(none):288" inside a VM), so they can never match their config.yaml entry — `iii worker add` times out after 120s reporting "not registered" even though the worker is connected and serving. This broke the quickstart (caller-worker) and the nightly quickstart-validator. Set workerName / WorkerMetadata.name explicitly to the iii.worker.yaml manifest name in every template worker that was missing it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughWorker registration is updated across five example workers to provide explicit identities. TypeScript workers pass ChangesWorker identity registration
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Why
The nightly quickstart-validator started failing after the iii 0.21.5 release:
iii worker add ./workers/caller-workertimes out after 120s with "not registered (engine has no worker under this name)" — even though the worker VM boots, connects, registersmath::add_two_numbers, and serves triggers correctly.Root cause
Since iii 0.21.5 (iii-hq/iii#1949, MOT-3931),
iii worker add --wait/status/listtrust only the worker names reported byengine::workers::list. A worker that never sets a name falls back to the SDK'shostname:piddefault —(none):288inside a libkrun VM — so it can never match its config.yaml entry name.The Python
math-workertemplate already passesInitOptions(worker_name="math-worker"), which is why step 3 of the quickstart passes and step 4 (the TypeScriptcaller-worker, which passed no name) hangs.Reproduced and verified locally with the released 0.21.5 binaries: before this change
iii worker add ./workers/caller-workertimes out at 120s whileiii trigger math::add_two_numbers a=10 b=20happily returns{"c":30}; withworkerName: 'caller-worker'added, the add completes with✓ caller-worker ready.What
Set
workerName/WorkerMetadata.nameexplicitly to theiii.worker.yamlmanifest name in every template worker that was missing it:iii/quickstart/workers/caller-worker(the validator failure)iii/multi-worker-orchestration/workers/clientiii/multi-worker-orchestration/workers/payment-workeriii/multi-worker-orchestration/workers/compute-worker(Rust —cargo checkpasses against published iii-sdk 0.20.0)iii/quickstart-ai-agents/workers/account-events(docker-based; attribution/console benefit only)Python templates already set names;
worker-barealready setsmy-worker.Follow-up (in iii-hq/iii)
The systemic fix — propagating
III_WORKER_NAMEinto managed worker VMs and having SDKs default to it — is being prepared in the iii repo so templates/user code never need to repeat the manifest name.🤖 Generated with Claude Code
Summary by CodeRabbit