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.

Bắt đầu với DurableHttp.callHttp và theo dõi cách DurableHttpRequest.getHttpRetryOptions được truyền vào ctx.callActivity, sau đó kiểm tra HttpRetryOptions và hành vi thử lại của TaskOptions. Xác định thứ tự ưu tiên cho TaskOptions được chỉ định tường minh, giữ nguyên việc lọc theo mã trạng thái và bổ sung mức độ bao phủ cho các trường hợp chỉ thử lại ở request, thành công, hết lần thử, loại trừ, lỗi truyền tải và các trường hợp tương tác. Cập nhật tài liệu API hoặc các ví dụ khi hành vi đã được xác định.