Supabase client retry behavior and PostgreSQL upsert interaction for idempotent writes

Goal: Ensure that a write operation retried by the Supabase client does not result in duplicate rows in the underlying PostgreSQL table.

The Supabase JavaScript SDK automatically retries failed network requests with exponential back‑off, but it does not deduplicate the corresponding INSERT or UPDATE statements. Developers must therefore rely on database‑level idempotency mechanisms such as ON CONFLICT upserts or unique constraints, or on Edge Functions that store an Idempotency-Key header in a uniquely constrained table.

Uncertainty remains about how SDK version differences affect retry limits and whether the client‑provided primary key must be generated before the first attempt to guarantee that retries target the same row.

Does the Supabase JS SDK allow disabling or customizing the automatic retry count for write calls?
When using ON CONFLICT DO NOTHING with a UUID primary key, must the UUID be generated client‑side before the initial request to prevent retries from creating a new identifier?
In an Edge Function that expects an Idempotency-Key header, what is the recommended behavior if the header is absent to avoid unintended duplicate writes?