Duplicate POST Writes Occur When HttpClient Retries After Timeout in Xamarin.Android

Answer first

Do not auto-retry non-idempotent POST on timeout. Generate a stable, persistent request-ID per logical operation and attach it as X-Request-ID. Persist the ID and a monotonic counter in SharedPreferences so it survives app restarts and process kills. Retry POST only when the server explicitly signals it is safe to repeat, e.g., via a Retry-After header or a custom X-Retry-Permitted: true response. A server-side request-ID alone is not sufficient; maintain a client-side persisted record of sent IDs to avoid re-sending after a crash before a response is received.

Confirmed facts vs likely explanation

Confirmed

• Xamarin.Android HttpClientHandler has no built-in retry mechanism.
• HttpClient does not generate a request-ID header automatically.
• A timeout results in TaskCanceledException on the client with no knowledge of server side effects.

Likely explanation for duplicates

On a transient network timeout the client assumes the request was not received and re-issues the same POST payload. If the server actually processed the first request, the retry creates a second record. This is a classic at-least-once vs at-most-once problem for non-idempotent methods.

Steps needed for this case

1. Stable request-ID that survives restarts

1. Obtain a device-stable base. Use Settings.Secure.ANDROID_ID. If unavailable or null, fall back to a randomly generated UUID saved once in SharedPreferences.
2. Maintain a monotonic counter persisted atomically in SharedPreferences. Example key: request_counter.
3. Compose request-ID as base + counter, e.g., {androidId}-{counter}. Increment and persist the counter before sending.
4. Store the last sent IDs with a timestamp in a small persisted set so the client can avoid re-using them after a crash.

Caution: ANDROID_ID can change on factory reset. The fallback UUID ensures continuity.

2. Attach ID and control retries

1. Add the ID to every HttpRequestMessage: request.Headers.Add("X-Request-ID", requestId).
2. Implement retry logic in a DelegatingHandler or via Polly. Retry only on transient transport errors.
3. For methods GET, HEAD, PUT, DELETE: retry on SocketException or timeout.
4. For POST: do NOT retry on timeout or TaskCanceledException. Retry only if the server response explicitly permits it, such as HTTP 408/504 with X-Retry-Permitted: true or a Retry-After header.
5. Propagate 4xx client errors without retry.

3. Client-side cache vs server header

Relying solely on a server-provided request-ID header is insufficient. The client may retry before any response is received, so the server never sees the first ID. A client-side persisted log of sent IDs ensures the same logical operation is not re-sent after a restart. Server-side deduplication using X-Request-ID is still required as a second line of defense.

Missing diagnostic detail that changes recommendation: does the server currently return any response body or status for a timed-out POST, or is the timeout purely client-side with zero bytes received? If the server returns a definitive 4xx/5xx before the timeout, the retry policy can be tightened further.