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

Events added to in-memory queue are not being raised after ContinueAsNew called. #676

Abierto
  • ¿Algo no está bien?
#331 5 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
azure, python
Área
backend, cloud

Línea de trabajo

Comienza con los ejemplos de orchestrator_function y HttpStarter en el issue y, a continuación, reproduce el comportamiento enviando dos solicitudes seguidas rápidamente. Rastrea cómo wait_for_external_event, raise_event y continue_as_new gestionan la cola de eventos en memoria. Se considera completado cuando el evento emitido después del procesamiento de la primera solicitud es recibido y procesado por el orquestador reiniciado.

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

Descripción

bug Enhancement fixed-in-v2 P2

🐛 Describe the bug
I had the exact same problem as described in the c# library (https://github.com/Azure/azure-functions-durable-extension/issues/676): only the first event is processed when raising event in a quick succession.

🤔 Expected behavior
I was expecting continue_as_new to resume the orchestrator_function and to pick the next event in the queue.

☕ Steps to reproduce

What Durable Functions patterns are you using, if any?

I was testing the singleton orchestrator patterns. Instead of directly invoking the orchestrator, I use raise_event to communicate with the orchestrator. The orchestrator listens to the incoming event with wait_for_external_event and triggers the processing.

Any minimal reproducer we can use?

The orchestrator function

def orchestrator_function(context: df.DurableOrchestrationContext):
    logging.warning("orchestrator starts")
    result = yield context.wait_for_external_event('wait_for_request')
    req = json.loads(result)
    yield context.call_activity('Hello1', json.dumps(req))
    yield context.call_activity('Hello1', json.dumps(req))
    yield context.call_activity('Hello1', json.dumps(req))
    logging.warning("orchestrator ends", req)
    context.continue_as_new(None)

The Hello1 activity function uses time.sleep(5) to simulate extended processing.

The HttpStarter

async def main(req: func.HttpRequest, starter: str) -> func.HttpResponse:
    client = df.DurableOrchestrationClient(starter)
    req_body = req.get_json()
    function_name = "orchestrator_function"

    h = hashlib.sha256()
    h.update(str.encode(req_body['endpoint']))
    instance_id = h.hexdigest()
    existing_instance = await client.get_status(instance_id)

    logging.warning(req_body)

    logging.warning(f"Start orchestration with ID = '{instance_id}'.")
    if existing_instance.runtime_status in [
            df.OrchestrationRuntimeStatus.Completed,
            df.OrchestrationRuntimeStatus.Failed,
            df.OrchestrationRuntimeStatus.Terminated,
            None]:
        instance_id = await client.start_new(function_name, instance_id, None)
        logging.warning(f"Started orchestration with ID = '{instance_id}'.")

    await client.raise_event(instance_id, 'wait_for_request', req_body)
    return client.create_check_status_response(req, instance_id)

When sending two HTTP requests to the HttpStarter consecutively (not simultaneously but with a bit gap), the orchestrator gets the first message and finishes the processing, but never picks up the second message.

Are you running this locally or on Azure?

I have tested both locally and on Azure. I currently work on a prototype that uses the singleton durable function to control the traffic to endpoints. Some endpoints may allow concurrent traffic and some may not.

⚡If deployed to Azure

We have access to a lot of telemetry that can help with investigations. Please provide as much of the following information as you can to help us investigate!

  • Timeframe issue observed: 2021-11-02
  • Function App name: tao-func-test1
  • Function name(s): adapter_controller (orchestrator), http_trigger (HttpStarter)
  • Azure region: US east
  • Orchestration instance ID(s): 5e0c90d2d434f24b1ec3df57316653d00de3cc27b2001902cd0983c18e381b78
  • Azure storage account name: taofunctest1

If you don't want to share your Function App or storage account name GitHub, please at least share the orchestration instance ID. Otherwise it's extremely difficult to look up information.

Lenguaje dominante
Python
Estrellas
157
Forks
70
Sin PR fusionados en 30 d

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

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 Azure/azure-functions-durable-python

Todos los issues de Azure/azure-functions-durable-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.