The resilience pipeline order is incorrect. The timeout is added before the retry strategy, which means the timeout applies to the entire operation including all retries, not to individual retry attempts. This should be reversed: add retry first, then timeout, so each retry attempt has its own timeout.

builder.AddRetry(newRetryStrategyOptions{ ...}).AddTimeout(newTimeoutStrategyOptions{ ...});

With the current order, ifPlacementTimeout is 30 seconds and retries take 10 seconds each, the operation would fail after 30 seconds even if retries are still within the retry limit.

That's precisely what we want.

Retrying onTimeoutException creates a logical conflict. When aTimeoutException is thrown by Polly's timeout strategy, retrying it will likely just hit the same timeout again. This exception should either not be retried, or the timeout configuration needs to be reconsidered (see comment about timeout/retry ordering).

If the intent is to handle timeouts from operationswithin the placement logic (not from Polly's timeout strategy), those should be caught and wrapped in a different exception type to distinguish them from Polly's timeout.

The message expiration check throws aTimeoutException, but the resilience policy is configured to retryTimeoutException (line 71 of OrleansRuntimeResiliencePolicies.cs). This means expired messages will be unnecessarily retried, which is wasteful since they will fail again immediately.

Consider using a different exception type for message expiration (e.g., a customMessageExpiredException orOperationCanceledException) that won't trigger retries, or exclude this specific case from retry logic.

Same issue as the first expiration check: thisTimeoutException will be retried by the resilience policy even though the message has already expired. See comment on lines 381-385.

The new resilience features for grain placement lack test coverage. Consider adding tests for:

• Retry behavior on transient failures
• Timeout behavior
• Interaction between timeout and retry policies
• Message expiration scenarios during retries
• Configuration options validation

This is especially important given the complexity of the retry/timeout interaction and the bugs identified in the resilience policy configuration.

The documentation states "This timeout applies to the entire placement operation including retries," which accurately describes the current implementation but may not be the intended behavior.

With the current pipeline order (timeout before retry), a single timeout covers all retry attempts. This means if retries take longer than the timeout duration, the operation will fail even if individual attempts would have succeeded.

If this is intentional, the documentation is correct. However, if each retry attempt should have its own timeout (which is more typical), this documentation should be updated to reflect that change when the pipeline order is corrected. See the comment on OrleansRuntimeResiliencePolicies.cs lines 36-58.

The package version forPolly.Extensions is 8.6.4 whilePolly is at 8.5.2. This version mismatch could lead to compatibility issues. Both packages should use the same major.minor version to ensure they work correctly together.