Problem
start_handling_loop passes maybe_handle_request.knowledge_interaction_id (the SC-assigned UUID/ID) to call(), but ki_registry is keyed by KI name. These never match in production — the SC assigns IDs at registration time; the registry stores entries under names like "my-answer-ki". This always raises KeyError for real incoming KI calls.
This is masked because TestClient.poll_ki_call is hardwired to return REPOLL, so the HANDLE branch is never exercised in any test.
Additionally, Client.post_handle_response exists but is neither in ClientProtocol nor called anywhere in the handling loop. Handler results are silently dropped; the SC never receives the reply.
Proposed solution
- Fix dispatch to look up by KI ID (e.g. maintain a secondary index in the registry, or change
call() to accept an ID).
- Add
post_handle_response to ClientProtocol.
- Wire the handling loop to send the handler result back to the SC after calling
call().
Benefits
- Incoming KI calls actually work end-to-end.
ClientProtocol reflects the full contract a SC adapter must honour.- The bug becomes impossible to reintroduce once test coverage closes the gap (see related issue).
Problem
start_handling_looppassesmaybe_handle_request.knowledge_interaction_id(the SC-assigned UUID/ID) tocall(), butki_registryis keyed by KI name. These never match in production — the SC assigns IDs at registration time; the registry stores entries under names like"my-answer-ki". This always raisesKeyErrorfor real incoming KI calls.This is masked because
TestClient.poll_ki_callis hardwired to returnREPOLL, so the HANDLE branch is never exercised in any test.Additionally,
Client.post_handle_responseexists but is neither inClientProtocolnor called anywhere in the handling loop. Handler results are silently dropped; the SC never receives the reply.Proposed solution
call()to accept an ID).post_handle_responsetoClientProtocol.call().Benefits
ClientProtocolreflects the full contract a SC adapter must honour.