Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
#73 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

@Epsilon006 is already working on this.

Since Sep 9, 2026.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
azure, python
Domain
api, backend

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.

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.

Dominant language
Python
Stars
19
Forks
11
Avg merge
5d 17h
Merged PRs (30d)
15

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/agent-framework-durable-extension

All issues in microsoft/agent-framework-durable-extension

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.