Apply DurableHttpRequest.HttpRetryOptions when scheduling durable HTTP retries

HttpRetryOptions is exposed on DurableHttpRequest, but DurableHttp.callHttp does not use that configuration to schedule retries unless the caller separately supplies TaskOptions. This is the Java retry-scheduling follow-up to Azure/azure-functions-durable-extension#1984, not a request to add a second HTTP API or retry-options type.

Current behavior

Checked v1.9.0 and main at cfdfbf505ed0c4b1b5e9d39a55504650f1dd09e8:

• HttpRetryOptions exposes intervals, maximum attempts, backoff, retry timeout, and status-code selection.
• DurableHttpRequest serializes those options under retryOptions for the HTTP activity.
• DurableHttp.callHttp(ctx, request) delegates with null TaskOptions. The implementation then calls ctx.callActivity without a retry policy; it does not derive one from request.getHttpRetryOptions().
• The extension's HTTP activity uses the configured status codes to turn matching responses into failures, but durable retry scheduling is separate from that failure classification.

Consequently, the code path for setting only the request's HttpRetryOptions does not schedule the configured retry attempts. Supplying a separate TaskOptions/RetryPolicy can schedule retries, but duplicates configuration and leaves the request-level attempt/backoff settings unapplied.

This finding is based on source-path inspection; an end-to-end failure/retry reproduction has not been executed.

Reproduction scenario

1. Configure a DurableHttpRequest with HttpRetryOptions specifying three attempts and HTTP 503 as retryable.
2. Call ctx.callHttp(request) without separate TaskOptions.
3. Use an endpoint that returns 503 for the first attempt and 200 for the next attempt.
4. Verify whether the orchestration schedules the second request using the request's retry policy rather than failing after the first HTTP activity.

Acceptance Criteria

• Apply the request's HttpRetryOptions to durable retry scheduling when no explicit scheduling override is supplied.
• Honor attempt limits, first/max intervals, backoff, and retry timeout, while retaining HTTP-status-code filtering.
• Define and document precedence when explicit TaskOptions and request-level HTTP retry options are both supplied.
• Preserve existing behavior when retry options are omitted.
• Add coverage for request-only retry configuration, retry-then-success, exhaustion, excluded status codes, transport failures, and explicit TaskOptions interaction.
• Update API documentation/examples so callers do not need two inconsistent policies for one HTTP request.

Related

• Original cross-language tracker: Azure/azure-functions-durable-extension#1984.
• Existing broad HTTP support tracker: microsoft/durabletask-java#39.
• HTTP API implementation: microsoft/durabletask-java#271.

从 DurableHttp.callHttp 开始，追踪 DurableHttpRequest.getHttpRetryOptions 如何传递给 ctx.callActivity，然后检查 HttpRetryOptions 和 TaskOptions 的重试行为。定义显式 TaskOptions 的优先级，保留状态码过滤，并为仅请求重试、成功、耗尽、排除、传输失败和交互情况添加覆盖。行为确定后，更新 API 文档或示例。