The current RequestContext / ServerRequestContext design has a few rough edges that warrant a dedicated refactor:
-
Request vs notification context — Request handlers have request_id and meta, notification handlers do not. Currently request_id is optional (RequestId | None) on a single shared type, which loses type safety. Ideally these would be distinct types so request handlers get a context where request_id is always present, and notification handlers get one where it does not exist.
-
Transport-specific context — The request_context field on ServerMessageMetadata is typed as Any because the server layer is transport-agnostic (e.g. it is a Starlette Request for HTTP transports, None for stdio). A better design would let transports provide their own typed context that handlers can access without casting.
These two concerns are related — both point toward making the context type more precise depending on how and where a handler is invoked.
AI Disclaimer
The current
RequestContext/ServerRequestContextdesign has a few rough edges that warrant a dedicated refactor:Request vs notification context — Request handlers have
request_idandmeta, notification handlers do not. Currentlyrequest_idis optional (RequestId | None) on a single shared type, which loses type safety. Ideally these would be distinct types so request handlers get a context whererequest_idis always present, and notification handlers get one where it does not exist.Transport-specific context — The
request_contextfield onServerMessageMetadatais typed asAnybecause the server layer is transport-agnostic (e.g. it is a StarletteRequestfor HTTP transports,Nonefor stdio). A better design would let transports provide their own typed context that handlers can access without casting.These two concerns are related — both point toward making the context type more precise depending on how and where a handler is invoked.
AI Disclaimer