Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

self communication pattern

Abierto
#105 6 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
python

Línea de trabajo

No se nombran archivos ni pruebas. Empieza siguiendo los métodos de envío de nivel inferior, la lógica de gestión de solicitudes y la ruta del broker; después, determina en qué se diferencian las solicitudes y respuestas locales de las remotas. Se considera terminado cuando el diseño elegido gestiona las llamadas locales sin bloquear, sigue entregando solicitudes y respuestas a consumidores remotos y define el comportamiento de las llamadas recursivas.

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

Descripción

enhancement major/framework effort

It is currently the case that an object in a dripline-python service cannot send requests to an endpoint in the same service. This is because the call stack send the request stops any python functions from processing the incoming request. There are a few pieces to resolving this:

  1. We should re-evaluate the potential use of async, it may be possible to resolve blocking with those patterns (probably requires across the board refactoring to make everything async compatible)
  2. The lower-level send methods should check if the target of the request is local, if so it should pass the request object to the request handling logic stack directly (rather than making a round trip to the broker). This places the resolution logic in the same call stack and avoid blocking.

There are some possible concerns:

  1. The above could result in an infinitely recursive loop (which should be stopped by the python recursion depth limit). It is not clear superficially if this is something we need to detect and protect against, or just document and "let it fail" for a user to fix.
  2. There could be cases where both a local and a remote consumer are expecting to receive a request, we need to make sure that the remote also gets it (for example, if I am running dl-mon to see all requests coming into some endpoint).
  3. If the request is sent locally, the reply needs to also be processed locally such that the original caller receives the reply in the expected type and format. This also has the same concern as 2, namely that there could also be a non-local client expecting to receive the result.
Lenguaje dominante
Python
Estrellas
3
Forks
6
Métricas de merge de PR
Sin PR fusionados en 30 d

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de driplineorg/dripline-python

Todos los issues de driplineorg/dripline-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.