Apply DurableHttpRequest.HttpRetryOptions when scheduling durable HTTP retries

從 DurableHttp.callHttp 開始，追蹤 DurableHttpRequest.getHttpRetryOptions 如何傳遞給 ctx.callActivity，然後檢查 HttpRetryOptions 和 TaskOptions 的重試行為。定義明確指定的 TaskOptions 的優先順序，保留狀態碼篩選，並為僅請求重試、成功、耗盡、排除、傳輸失敗和互動情況新增涵蓋範圍。行為確定後，更新 API 文件或範例。

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.