Events added to in-memory queue are not being raised after ContinueAsNew called. #676
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 3/5
- Tempo estimado
- 1-2 dias
- Facilidade para iniciantes
- 45/100
Direção de pesquisa
Comece pelos exemplos de orchestrator_function e HttpStarter na issue e, em seguida, reproduza o comportamento enviando duas solicitações em rápida sucessão. Rastreie como wait_for_external_event, raise_event e continue_as_new lidam com a fila de eventos na memória. Está concluído quando o evento disparado após o processamento da primeira solicitação é recebido e processado pelo orquestrador reiniciado.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
🐛 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.
- Linguagem predominante
- Python
- Estrelas
- 157
- Forks
- 71
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Preparar o ambiente
Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de Azure/azure-functions-durable-python
-
Enhancement fixed-in-v2 P3
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
Azure/azure-functions-durable-python#617 · 1 comentário ·
-
bug Debuggability fixed-in-v2 P2
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
Azure/azure-functions-durable-python#587 · 2 comentários · 1 reação ·
-
Custom object serialization broken for orchestrator return valuesTalvez já em andamento @andystaples assumiu há 80 dias. Abertabug fixed-in-v2 P2
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
Azure/azure-functions-durable-python#568 · 1 comentário ·
-
bug fixed-in-v2 P3
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
Azure/azure-functions-durable-python#475 · 1 comentário ·
-
Enhancement fixed-in-v2 P3
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 62/100
Azure/azure-functions-durable-python#618 · 1 comentário ·
Todas as issues de Azure/azure-functions-durable-python
Issues semelhantes
-
Edit tool converts CRLF files to LFTalvez já em andamento @RaphaelFakhri assumiu hoje. Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
huggingface/tau#774 ·
Mantenedores costumam responder em até 1 dia
-
show ignores the row limit when a column or table name contains "limit"Talvez já em andamento @RaphaelFakhri assumiu hoje. Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 84/100
Mantenedores costumam responder em até 2 dias
-
documentation good first issue
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
eclipse-score/inc_someip_gateway#356 ·
Mantenedores costumam responder em até 2 dias