danielgtaylor / danielgtaylor/python-betterproto

unary_stream message issue

Abierto
#430 1 comentario 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
Python
Estrellas
1.8k
Forks
234
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

I'm currently facing the issue that a unary_stream connection does not behave as I would expect. (betterproto version b5)

## Client code:
![image](https://user-images.githubusercontent.com/79153884/193418261-880ae8b2-75bf-4ee5-a707-72404a92637c.png)

## Server code:
![image](https://user-images.githubusercontent.com/79153884/193418299-f9e63c37-e4a3-4ecb-a32a-ae76b1103c33.png)
![image](https://user-images.githubusercontent.com/79153884/193418312-331223ad-8c15-43e9-ba5f-0d46b8617b38.png)

Opening the connection works fine, the server receives the request and begins its job.
The task the server performs is taking 1 min +/-, during that time it sends multiple responses to the client.
While debugging I could see that subroutines have been executed and sending data (server side).

But nothing arrives at the client, the red X located at the client if statement is a breakpoint that never executes until after the server method returns. If I breakpoint the server at its last statement (red X) the client is idle. Only after continuing, allowing the server to complete the method (closing the connection?), within the client program the subroutines trigger:
![image](https://user-images.githubusercontent.com/79153884/193418482-1e8314d9-753c-4c9d-9db5-f473a0fda2d5.png)

All messages then are 'spammed' to the waiting client. At first glance, nothing is missing, but I expected the stream to work like in the default google implementation. Receiving the messages one after another when sent from the server.
Is this intended behavior?

Guía de contribución

Abrir la guía de contribución

Línea de trabajo

Reproduce el ejemplo unary_stream de cliente y servidor mostrado en el issue con betterproto b5 y observa cuándo recibe mensajes el cliente mientras el servidor sigue ejecutándose. Compara ese comportamiento con la semántica de streaming esperada y determina si la entrega antes de que retorne el método del servidor es intencionada; se considera terminado cuando el comportamiento esté explicado y estén claros el cambio apropiado en el proyecto o el alcance de las pruebas.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
grpc, python
Área
backend-api-design
Tipo de issue
Error
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Estancado
Claridad
Necesita aclaración
Aptitud para principiantes
30/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.