Summary
Bring create_check_status_response() and wait_for_completion_or_create_check_status_response() into parity with the Durable Functions HTTP management API.
This groups the closely related response-status, polling-header, and status-query URL behavior into one focused change.
Current behavior
create_check_status_response() omits the standard Retry-After: 10 header that both the v1 Python SDK and the Durable Functions host emit for the asynchronous HTTP pattern.
wait_for_completion_or_create_check_status_response() returns HTTP 500 unconditionally for failed orchestrations.
- Callers cannot opt into
returnInternalServerErrorOnFailure when creating a check-status response or management payload.
The Durable Functions host defaults failed status queries to HTTP 200 and returns HTTP 500 only when returnInternalServerErrorOnFailure=true is requested. See Azure/azure-functions-durable-python#314.
Expected behavior
Add a Python-style return_internal_server_error_on_failure: bool = False option and apply it consistently across:
- async
create_check_status_response();
- sync
create_check_status_response();
create_http_management_payload();
wait_for_completion_or_create_check_status_response().
When enabled, statusQueryGetUri must include returnInternalServerErrorOnFailure=true. The wait helper must return HTTP 200 for a failed orchestration by default and HTTP 500 only when the option is enabled. Timeout responses must preserve the option in their status-query URL.
Acceptance criteria
- Check-status responses include
Location, Content-Type: application/json, and Retry-After: 10.
- Failed orchestrations return HTTP 200 by default from the wait helper.
- Failed orchestrations return HTTP 500 when
return_internal_server_error_on_failure=True.
- Generated
statusQueryGetUri includes the host query parameter only when enabled.
- Async and sync clients have matching behavior.
- Unit tests cover initial responses, timeout responses, and completed/terminated/failed terminal states.
Summary
Bring
create_check_status_response()andwait_for_completion_or_create_check_status_response()into parity with the Durable Functions HTTP management API.This groups the closely related response-status, polling-header, and status-query URL behavior into one focused change.
Current behavior
create_check_status_response()omits the standardRetry-After: 10header that both the v1 Python SDK and the Durable Functions host emit for the asynchronous HTTP pattern.wait_for_completion_or_create_check_status_response()returns HTTP 500 unconditionally for failed orchestrations.returnInternalServerErrorOnFailurewhen creating a check-status response or management payload.The Durable Functions host defaults failed status queries to HTTP 200 and returns HTTP 500 only when
returnInternalServerErrorOnFailure=trueis requested. See Azure/azure-functions-durable-python#314.Expected behavior
Add a Python-style
return_internal_server_error_on_failure: bool = Falseoption and apply it consistently across:create_check_status_response();create_check_status_response();create_http_management_payload();wait_for_completion_or_create_check_status_response().When enabled,
statusQueryGetUrimust includereturnInternalServerErrorOnFailure=true. The wait helper must return HTTP 200 for a failed orchestration by default and HTTP 500 only when the option is enabled. Timeout responses must preserve the option in their status-query URL.Acceptance criteria
Location,Content-Type: application/json, andRetry-After: 10.return_internal_server_error_on_failure=True.statusQueryGetUriincludes the host query parameter only when enabled.