Apply DurableHttpRequest.HttpRetryOptions when scheduling durable HTTP retries

Beginne mit DurableHttp.callHttp und verfolge, wie DurableHttpRequest.getHttpRetryOptions an ctx.callActivity übergeben wird. Untersuche anschließend HttpRetryOptions und das Wiederholungsverhalten von TaskOptions. Lege die Priorität für explizite TaskOptions fest, bewahre die Filterung nach Statuscode und ergänze Tests für Wiederholungen nur auf Anfrageebene, Erfolg, Erschöpfung, Ausschlüsse, Transportfehler und Interaktionsfälle. Aktualisiere die API-Dokumentation oder Beispiele, sobald das Verhalten festgelegt ist.

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.