Skip to content

add support for RPC interceptors - #806

Open
davidzhao wants to merge 4 commits into
mainfrom
dz/intercepters
Open

add support for RPC interceptors#806
davidzhao wants to merge 4 commits into
mainfrom
dz/intercepters

Conversation

@davidzhao

Copy link
Copy Markdown
Member

allowing telemetry hooks so we can provide automatic traces when used in agents.

allowing telemetry hooks so we can provide automatic traces when used in
agents.
devin-ai-integration[bot]

This comment was marked as resolved.

…identity

Review follow-ups on the interceptor hook:

- The caller's response_timeout now covers the whole incoming chain
  (_run_incoming_chain wraps interceptors + handler in one wait_for), so time
  an interceptor spends before or after next() counts against it instead of
  handing the handler a fresh full timeout. Deadline expiry cancels the chain
  and maps to RESPONSE_TIMEOUT; cancellation from outside (room disconnect)
  still maps to RECIPIENT_DISCONNECTED. _invoke_rpc_handler no longer wraps
  the handler itself.
- add_rpc_interceptor / remove_rpc_interceptor compare by identity, so two
  distinct interceptors that compare equal coexist and only the exact instance
  is removed.
- mypy: cast the awaited handler result; fix the non-overlapping identity
  check in the test.

Tests: deadline burned before and after next(), outside cancellation,
identity registration; the timeout test now asserts interceptors observe the
cancellation.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
devin-ai-integration[bot]

This comment was marked as resolved.

asyncio.wait_for raises the same TimeoutError a handler or interceptor might
raise on its own (an HTTP client timing out, say), so _run_incoming_chain
reported both as RESPONSE_TIMEOUT. The pre-existing handler wrapper had the
same conflation, but now that the deadline spans the chain it is cheap to get
right: a TimeoutError raised inside the chain is tagged (_ChainTimeoutError)
and re-raised as the original exception, which _handle_rpc_method_invocation
maps to APPLICATION_ERROR like any other handler failure; only wait_for's own
expiry becomes RESPONSE_TIMEOUT.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
devin-ai-integration[bot]

This comment was marked as resolved.

…ng error

wait_for reported whatever the chain raised while being cancelled; an
interceptor that catches the cancellation and raises during cleanup could turn
a deadline expiry into APPLICATION_ERROR (or, via the TimeoutError tag, back
into a mislabelled application timeout).

The chain now runs as its own future under a call_later deadline that sets a
flag before cancelling it. Once the flag is set, anything the chain raises
while unwinding is reported as RESPONSE_TIMEOUT; a CancelledError without the
flag is external cancellation and stays RECIPIENT_DISCONNECTED; any exception
before the deadline, TimeoutError included, propagates as an application
error. The _ChainTimeoutError tag is no longer needed.

Tests: cleanup raising TimeoutError and RuntimeError after the deadline both
map to RESPONSE_TIMEOUT; the existing deadline, in-chain timeout and outside
cancellation cases still hold.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant