Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#331 5 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Calme
Stack technique
azure, python
Domaine
backend, cloud

Piste de recherche

Commencez par les exemples de orchestrator_function et HttpStarter dans l’issue, puis reproduisez le comportement en envoyant deux requêtes à la suite, rapidement. Suivez la manière dont wait_for_external_event, raise_event et continue_as_new gèrent la file d’événements en mémoire. C’est terminé lorsque l’événement déclenché après le traitement de la première requête est reçu et traité par l’orchestrateur redémarré.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Python
Étoiles
157
Forks
71
Aucune PR mergée en 30 j

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de Azure/azure-functions-durable-python

Toutes les issues de Azure/azure-functions-durable-python

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.