Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Python: Azure Functions samples each hand-roll an orchestration status endpoint

Aperta
#73 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 3 giorni

@Epsilon006 ci sta già lavorando.

Dal 9/9/2026.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
azure, python
Ambito
api, backend

Direzione di ricerca

Confronta gli endpoint di stato negli esempi di orchestrazione dal 04 al 07 con _is_owned_orchestration in _app.py e analizza l’idioma di registrazione esistente di add_agent. Decidi il contratto di risposta predefinito e come mantenere possibili gli endpoint personalizzati, quindi implementa il blocco costitutivo condiviso e la registrazione con ambito, migra gli esempi e mantieni un esempio personalizzato. Il lavoro è completato quando le ricerche dello stato sono limitate alla proprietà e gli esempi non duplicano più la forma standard dell’endpoint.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

The four orchestration samples (04 to 07) each define their own GET .../status/{instanceId} endpoint. They are near identical, roughly 40 lines each plus a duplicated _build_status_url, and the shapes have already drifted. 04 returns four fields, 05 and 06 add timestamps, 07 adds custom status and failure details instead.

Two problems with that.

None of them scope the lookup by orchestration name. The durable client resolves instance IDs across the whole task hub, so handing one of these endpoints an ID from a different orchestration returns that orchestration's status. AgentFunctionApp already guards this for workflow endpoints, see _is_owned_orchestration in _app.py. The samples are demonstrating the unsafe shape and people copy samples.

The response contract also lives in four places with nothing keeping them in sync.

Rough proposal, two tiers so custom endpoints stay possible.

A building block that turns an OrchestrationState into the response dict, so anyone writing their own endpoint gets the shape and the PascalCase runtime status without hand rolling it.

A convenience registration on the app that wires up a scoped endpoint, following the existing add_agent idiom.

app.add_orchestration_status_route("single_agent_orchestration", route="singleagent/status/{instanceId}")

That would do the ownership check internally so callers cannot forget it. Samples move to the one liner, except one that keeps the hand written endpoint to show how to customise the response.

Worth deciding what the default response contains, since the current four disagree. My instinct is to leave input out, echoing the caller's payload back on a status URL is the field most likely to expose something unwanted.

If this lands, the runtime_status_name export added in #72 may not need to stay public.

Lingua principale
Python
Stelle
19
Fork
11
Merge medio
4g 23h
PR unite (30g)
14

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/agent-framework-durable-extension

Tutte le issue di microsoft/agent-framework-durable-extension

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.