Skip to content

.NET: Support returning durable workflow results from HTTP trigger endpoint - #5321

Merged
Shyju Krishnankutty (kshyju) merged 6 commits into
mainfrom
shkr/workflow_return_value
Apr 25, 2026
Merged

.NET: Support returning durable workflow results from HTTP trigger endpoint#5321
Shyju Krishnankutty (kshyju) merged 6 commits into
mainfrom
shkr/workflow_return_value

Conversation

@kshyju

Copy link
Copy Markdown
Contributor

Summary

Adds support for synchronously returning workflow execution results from the HTTP trigger endpoint. By default, the workflow HTTP endpoint fires-and-forgets (202 Accepted). With this change, callers can set the x-ms-wait-for-response: true header to wait for the workflow to complete and receive the result directly in the HTTP response (200 OK). Results are returned as plain text by default, or as a structured JSON object when Accept: application/json is specified.

Changes

New feature

  • Parse the x-ms-wait-for-response header in RunWorkflowOrchestrationHttpTriggerAsync
  • New WaitForWorkflowCompletionAsync method that calls WaitForInstanceCompletionAsync and handles failure/completed/unexpected statuses
  • Support Accept: application/json header to return a structured JSON response (runId, status, result)
  • POCO results from executors are properly serialized as nested JSON objects (using JsonElement) rather than double-encoded strings

Code quality improvements

  • Extracted WaitForResponseHeaderName constant (replaces two inline string literals)
  • Extracted ShouldWaitForResponse(req, defaultValue) helper to eliminate duplicated header-parsing logic across workflow and agent triggers
  • Extracted AcceptsJson(req) helper to deduplicate Accept header checks across 4 response methods
  • Added optional acceptsJson parameter to CreateErrorResponseAsync to avoid redundant header reads within WaitForWorkflowCompletionAsync

Docs & samples

  • Updated 01_SequentialWorkflow/README.md with curl/PowerShell examples for the new header
  • Added demo.http entries for wait-for-response scenarios (plain text and JSON)

Tests

  • Added integration test in WorkflowSamplesValidation.cs verifying the header works end-to-end

JSON response examples

Plain text (default):

Cancellation email sent for order 12345 to jerry@example.com.

JSON (with Accept: application/json):

{
"runId": "abc123def456",
"status": "Completed",
"result": "Cancellation email sent for order 12345 to jerry@example.com."
}

JSON with POCO result (executor returns an object):

{
"runId": "abc123def456",
"status": "Completed",
"result": { "orderId": 123, "email": "jerry@example.com" }
}

Description

Contribution Checklist

  • The code builds clean without any errors or warnings
  • The PR follows the Contribution Guidelines
  • All unit tests pass, and I have added new tests where possible
  • Is this a breaking change? If yes, add "[BREAKING]" prefix to the title of the PR.

@moonbox3Evan Mattson (moonbox3) added documentation Usage: [Issues, PRs], Target: documentation in the code base and learn docs .NET Usage: [Issues, PRs], Target: .Net labels Apr 17, 2026

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds an opt-in “wait for completion” mode to the Azure Functions HTTP workflow trigger so callers can synchronously receive workflow results (plain text by default, JSON when Accept: application/json is provided), along with docs, samples, and an integration test update.

Changes:

  • Add x-ms-wait-for-response support for workflow HTTP trigger and refactor shared header parsing helpers.
  • Add synchronous completion wait path that returns 200 OK with either plain text or structured JSON (runId, status, result).
  • Update samples/docs and add an end-to-end integration test for the new header behavior.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.

Show a summary per file
FileDescription
dotnet/src/Microsoft.Agents.AI.Hosting.AzureFunctions/BuiltInFunctions.csImplements wait-for-completion HTTP response path and consolidates header parsing helpers.
dotnet/tests/Microsoft.Agents.AI.Hosting.AzureFunctions.IntegrationTests/WorkflowSamplesValidation.csAdds an integration test covering the wait-for-response header for workflows.
dotnet/src/Microsoft.Agents.AI.Hosting.AzureFunctions/CHANGELOG.mdAdds an Unreleased changelog entry for the new HTTP trigger behavior.
dotnet/samples/04-hosting/DurableWorkflows/AzureFunctions/01_SequentialWorkflow/demo.httpAdds request examples demonstrating wait-for-response (plain text + JSON).
dotnet/samples/04-hosting/DurableWorkflows/AzureFunctions/01_SequentialWorkflow/README.mdDocuments how to wait for workflow results and request JSON responses.

Comment threaddotnet/src/Microsoft.Agents.AI.Hosting.AzureFunctions/BuiltInFunctions.cs Outdated
Comment threaddotnet/src/Microsoft.Agents.AI.Hosting.AzureFunctions/BuiltInFunctions.cs Outdated
Comment threaddotnet/src/Microsoft.Agents.AI.Hosting.AzureFunctions/BuiltInFunctions.cs Outdated
Comment threaddotnet/src/Microsoft.Agents.AI.Hosting.AzureFunctions/BuiltInFunctions.cs Outdated
Comment threaddotnet/src/Microsoft.Agents.AI.Hosting.AzureFunctions/BuiltInFunctions.cs Outdated
Comment threaddotnet/src/Microsoft.Agents.AI.Hosting.AzureFunctions/BuiltInFunctions.cs Outdated
- Return 404 Not Found when no orchestration with the given ID exists
- Return 200 OK for failed workflows (the HTTP operation succeeded;
the workflow outcome is conveyed via the response body)
- Rename 'status' to 'workflowStatus' in WorkflowRunResponse to avoid
inconsistency with AgentRunSuccessResponse which uses integer status
- Add optional 'error' field (omitted from JSON when null) to
WorkflowRunResponse for failed workflow details
@github-merge-queue
github-merge-queueBot removed this pull request from the merge queue due to failed status checks Apr 24, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentationUsage: [Issues, PRs], Target: documentation in the code base and learn docs.NETUsage: [Issues, PRs], Target: .Net

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

@kshyju@cgillum@ahmedmuhsin@moonbox3