microsoft / microsoft/agent-framework-durable-extension
Python: Azure Functions samples each hand-roll an orchestration status endpoint
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 16
- Forks
- 10
- Avg merge
- 3d 9h
- Merged PRs (30d)
- 9
Description
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Compare the status endpoints in orchestration samples 04 through 07 with _is_owned_orchestration in _app.py, and inspect the existing add_agent registration idiom. Decide the default response contract and how custom endpoints remain possible, then implement the shared building block and scoped registration, migrate the samples, and keep one customized example. Done means status lookups are ownership-scoped and the samples no longer duplicate the standard endpoint shape.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, python
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100