Refactor handler context to be transport- and handler-type-aware
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Refactorización
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- python
- Área
- backend-api-design
Línea de trabajo
Empieza siguiendo RequestContext y ServerRequestContext a través de los puntos de entrada de los handlers; después, inspecciona ServerMessageMetadata.request_context y los casos de transporte mencionados para Starlette Request y stdio. Compara cómo reciben el contexto los handlers de requests y notifications y cómo se accede a los valores específicos del transporte. Se considera terminado cuando los límites de tipos previstos y el comportamiento del transporte están definidos sin depender de Any ni de IDs de request opcionales.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The current RequestContext / ServerRequestContext design 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.
- Lenguaje dominante
- Python
- Estrellas
- 24.3k
- Forks
- 4k
- Merge medio
- 1 d 16 h
- PR fusionados (30 d)
- 25
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de modelcontextprotocol/python-sdk
-
v1 v2
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
modelcontextprotocol/python-sdk#3578 · 1 comentario ·
-
v1 v2
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
modelcontextprotocol/python-sdk#3573 · 2 comentarios ·
-
v2
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
modelcontextprotocol/python-sdk#3566 ·
-
Streamable HTTP client logs a WARNING for valid 202 Accepted on session termination (DELETE) Abiertov1 v2
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
modelcontextprotocol/python-sdk#3546 · 5 comentarios ·
-
v1 v2
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
modelcontextprotocol/python-sdk#3545 · 2 comentarios ·
Todos los issues de modelcontextprotocol/python-sdk
Issues similares
-
[Bug] reef-hermes tells me to resume with hermes --resume, which does not work from my shell Abiertoarea: harness bug status: needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Human-Agent-Society/reef#625 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 80/100
learningequality/kolibri#15351 · 2 comentarios ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Name consistency Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
eellak/triplestore#65 · 1 comentario ·