microsoft / microsoft/agent-framework-durable-extension

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

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

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

Open the contributing guide

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.

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.