Apply DurableHttpRequest.HttpRetryOptions when scheduling durable HTTP retries

Comece com DurableHttp.callHttp e rastreie como DurableHttpRequest.getHttpRetryOptions é passado para ctx.callActivity; em seguida, examine HttpRetryOptions e o comportamento de novas tentativas de TaskOptions. Defina a precedência para TaskOptions explícitos, preserve a filtragem por código de status e adicione cobertura para novas tentativas somente da requisição, sucesso, esgotamento, exclusões, falhas de transporte e casos de interação. Atualize a documentação da API ou os exemplos quando o comportamento estiver definido.

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.