feat(client): add InitClient for the deferred-init endpoints#243
feat(client): add InitClient for the deferred-init endpoints#243VascoSch92 wants to merge 2 commits into
Conversation
Adds coverage for the warm-pool deferred-init routes the client was missing: - GET /api/init -> InitClient.getStatus() - POST /api/init -> InitClient.initialize() (sends the bootstrap X-Init-API-Key header, distinct from the per-session key) New src/client/init-client.ts, InitState/InitStatus/InitRequest model types, exports from clients.ts and index.ts, and an `init` namespace on ConversationManager. Includes unit tests (namespace wiring, getStatus, initialize with and without the init key) and an integration contract guard (both routes 404 on the non-deferred pinned image, proving the paths/methods exist).
Endpoint audit❌ 7 off-contract call(s) — not on the agent-server · classifiers: cloud
❌ Not on agent-server (gated, 7)⛔ (no known backend) — served by no backend we can see (6)
|
|
✅ Review complete. This review was performed through OpenHands Cloud Automation. You can log in and view the conversation here. |
all-hands-bot
left a comment
There was a problem hiding this comment.
Reviewed this end-to-end. The implementation is small, idiomatic, and follows the conventions established by BashClient, HooksClient, etc. — HttpClient wrapper, host.replace(/\/$/, '') normalization, close() parity, model types colocated in models/api.ts, exposed via clients.ts and index.ts. The deferred-init integration test is genuinely useful: asserting 404 (not 405/422) proves both that the routes exist on the pinned image and that the client targets the right path/method — that's a real contract test, not a mock-pile. CI is green across all 11 checks. Two minor doc clarifications below; otherwise ready to merge.
This review was generated by an AI agent (OpenHands) on behalf of the user through OpenHands Automation. View conversation
|
@OpenHands address the comments and fix the conflicts. |
|
I'm on it! VascoSch92 can track my progress at all-hands.dev |
Resolve conflicts with main and clarify InitClient header behavior. Co-authored-by: openhands <openhands@all-hands.dev>
|
Done — PR #243 is updated: #243 Summary:
Validation:
Current PR state: conflicts are fixed; merge is still blocked only by required review ( |
Summary
Split from #231 (one feature per PR). Adds client coverage for the warm-pool deferred-init endpoints that the audit reported as missing. Implementations follow the agent-server init router in
OpenHands/software-agent-sdk(see software-agent-sdk#2523).GET /api/initInitClient.getStatus()POST /api/initInitClient.initialize()(sendsX-Init-API-Key)Details
src/client/init-client.tswraps the deferred-init / warm-pool endpoints.POST /api/initauthenticates with the bootstrapX-Init-API-Keyheader (distinct from the per-sessionX-Session-API-Key); it is omitted when no key is given.InitState/InitStatus/InitRequestadded tomodels/api.tsand exported fromindex.ts.InitClientexported fromclients.tsand wired intoConversationManageras theinitnamespace (constructed and closed alongside the other clients).Testing
src/__tests__/api-clients.test.ts, mockedfetch):initnamespace wiring,getStatusGET,initializePOST (header + body present), andinitializeomitting the header when no key is given.deterministic-api.integration.test.ts): both routes return404on the non-deferred pinned image (get_init_serviceanswers 404 when noInitServiceis registered) — proving the GET/POST routes exist on the image and the client targets the right path/method.npm run build,lint(0 errors), andformat:checkpass; full unit suite green (273).