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

Webhook-based worker wake-up: let DTS call a user-provided endpoint to scale up idle workers (agents)

Open
  • Is something wrong?
#11 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
42/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
python
Domain
backend-api-design, distributed-systems

Research direction

No source files or tests are named. Start by tracing the task-hub path that detects pending work without a connected worker and the worker connection path; then identify how endpoint configuration and orchestration instance and conversation IDs are represented. Done means a configured endpoint receives the wake request and a newly connected worker resumes the correct queued context.

Written by the indexing model from the issue text.

Description

Summary

Add outbound webhook support to the Durable Task Scheduler so a customer can register an HTTP endpoint that DTS calls when there is pending work and no worker connected to pick it up. The wake request includes the identifiers needed to resume the right context, including the conversation ID, so the worker that comes up continues the agent exactly where it left off instead of starting a blank session. Once the worker connects, it pulls and processes the queued work as usual.

Problem

DTS is pull based. A worker has to be alive and connected to receive work. That assumption breaks when the worker is hosted somewhere that scales to zero on idle, such as a Foundry Hosted Agent, which deprovisions compute after a period of inactivity. If an event is raised while the worker is scaled down, for example a human in the loop approval or a timer firing, the work sits in the task hub with no worker alive to pull it, and DTS has no way to reach out and wake the host. Waking a worker is only half the problem. The agent's session state lives separately, keyed by conversation ID, so the resumed worker also has to know which conversation to restore or it comes back up with no memory of the run it is supposed to continue.

Proposed solution

Let the customer configure a wake up endpoint on the task hub. When DTS detects pending work with no connected worker, it sends an HTTP request to that endpoint. The request carries the identifiers required to resume the correct context, including the orchestration instance ID and the associated conversation ID. The customer's environment uses those to bring the right worker back up, which reconnects to DTS, restores the agent session for that conversation ID, and drains the pending work. This gives pull based workers the same "someone rings the doorbell when there is work" behavior that push based and HTTP triggered systems already have, while making sure the agent picks up where it left off.

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

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.