[RFC]: Lazy state changes.
Les mainteneurs répondent en général sous 4 jours
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 25/100
- Type d'issue
- Fonctionnalité
- Clarté
- À clarifier
- Activité
- À l'abandon
- Stack technique
- python
- Domaine
- backend-api-design, networking
Piste de recherche
Commencez par l’API documentée H2Connection.receive_data et la séquence d’événements de l’issue ; comparez son contrat actuel qui renvoie une liste avec le comportement proposé de lazy generator. La tâche est terminée lorsqu’une décision du projet a été prise quant à l’acceptation du breaking API change et que l’orientation qui en résulte a été consignée ; aucun fichier d’implémentation ni aucun test n’est indiqué dans l’issue.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Inspired by @njsmith in njsmith/h11#4.
Right now there is a wart in the h2 API when working on a busy connection. The problem exists when working with receive_data. For example, it is possible that you might encounter the following set of events returned from receive_data: [DataReceived(stream_id=1), WindowUpdated(stream_id=1), StreamReset(stream_id=1)].
In response to that WindowUpdated you may want to send another data frame on stream 1, but if you do so without processing the entire event list h2 will throw a ProtocolError at you because the stream is now in the CLOSED state. However, the user doesn't know that: they're processing the events serially, and haven't gotten to the event that actually closed the stream.
The outcome of this is not too bad: while the ProtocolError does get thrown, the connection state is still fine and no damage has been done to your ability to continue to use the connection. However, the exception may cause an incautious user to run into trouble: if they're not expecting and handling this exception it'll quite probably cause them to lose a lot of application state.
In njsmith/h11#4, @njsmith has proposed a split API for receiving data: a single receive_data call returns no events, but instead you need to call next_event to advance the state machine. This proposal is essentially a "split" API much like we have for sending.
Making that change is a pretty substantial API change and I don't know how I feel about it. However, it turns out that hyper-h2 is capable of emulating that change with a very simple change to the logic of receive_data.
Right now, receive_data returns a list of events. However, it would be a trivial change for receive_data to return a generator instead. That generator would then iterate across events, one event at a time. The effect of doing that would be to avoid updating the state machines until the user has an event in hand, and would essentially immediately change hyper-h2 to an API that lazily updates stream state. This would ensure that a user cannot see a ProtocolError for sending data on a closed stream unless they have iterated past an event that closed the stream (or they closed it themselves).
I'm interested in what @python-hyper/contributors think, as well as our wider user-base. I think making such a change would be extremely valuable, but it represents a breaking API change (receive_data is documented as returning a list).
Do people think this change is sensible?
- Langage dominant
- Python
- Étoiles
- 1k
- Forks
- 197
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de python-hyper/h2
-
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
python-hyper/h2#1330 ·
Les mainteneurs répondent en général sous 4 jours
-
content-length is not policed when a stream ends with a trailers sectionPeut-être pris @feiiiiii5 l’a pris il y a 30 jours. Ouverte
Difficulté 3/5 1-2 jours Accessibilité débutants 76/100
python-hyper/h2#1328 ·
Les mainteneurs répondent en général sous 4 jours
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 35/100
python-hyper/h2#1312 ·
Les mainteneurs répondent en général sous 4 jours
-
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
python-hyper/h2#1280 · 2 commentaires ·
Les mainteneurs répondent en général sous 4 jours
-
Difficulté 3/5 1-2 jours Accessibilité débutants 45/100
python-hyper/h2#1239 · 3 réactions ·
Les mainteneurs répondent en général sous 4 jours
Toutes les issues de python-hyper/h2
Issues similaires
-
The changelog workflow excludes otelbot but not dependabot, so every Dependabot pull request fails the changelog checkPeut-être pris @ocelotl l’a pris aujourd’hui. Ouverte
Difficulté 1/5 Moins d'une heure Accessibilité débutants 82/100
open-telemetry/opentelemetry-python#5825 ·
Les mainteneurs répondent en général sous 2 jours
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
cuga-project/cuga-agent#1020 ·
Les mainteneurs répondent en général sous 2 jours
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 70/100
microsoft/playwright#43640 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
stac-utils/stac-fastapi-elasticsearch-opensearch#965 ·
Les mainteneurs répondent en général sous 2 jours
-
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
Les mainteneurs répondent en général sous 1 jour