<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Idempotency on TaskFused.com</title>
    <link>https://taskfused.com/tags/idempotency/</link>
    <description>Recent content in Idempotency on TaskFused.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 18 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://taskfused.com/tags/idempotency/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Client Retries After a Timeout With TaskFused, the Second Request Joins the First</title>
      <link>https://taskfused.com/client-retries-after-a-timeout-with-taskfused-the-second-request-joins-the-first/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://taskfused.com/client-retries-after-a-timeout-with-taskfused-the-second-request-joins-the-first/</guid>
      <description>&lt;p&gt;A phone app sends &amp;ldquo;import my contacts&amp;rdquo; to your server. The import takes twelve seconds, but the app gives up after ten, because that&amp;rsquo;s what its HTTP client does by default. It shows a spinner and sends the request again. Now the server is running two imports of the same contacts into the same account, and the user ends up with every contact twice.&lt;/p&gt;&#xA;&lt;p&gt;Retries like that are normal and mostly good. Networks drop replies, phones switch from Wi-Fi to mobile data, and a client that never retried would leave users stuck. The trouble is a retry that can&amp;rsquo;t tell it&amp;rsquo;s a retry. TaskFused gives the server a way to tell.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Payments and Emails With TaskFused, Using the Operation ID as the Idempotency Key</title>
      <link>https://taskfused.com/payments-and-emails-with-taskfused-using-the-operation-id-as-the-idempotency-key/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://taskfused.com/payments-and-emails-with-taskfused-using-the-operation-id-as-the-idempotency-key/</guid>
      <description>&lt;p&gt;A shop charges a customer&amp;rsquo;s card when they confirm an order, then sends the receipt. The confirm button gets double-clicked, the request gets retried, and a worker might crash at any point. Two charges for one order is the one outcome that must never happen, and a second receipt is embarrassing.&lt;/p&gt;&#xA;&lt;p&gt;TaskFused already stops the double click and the retry from doing anything twice: they join the same operation. But it runs each operation at least once, and that leaves one gap. A worker can charge the card and then die before it saves &amp;ldquo;done&amp;rdquo;. The lease runs out, another worker takes the operation over, and that worker charges again. This post is about closing that gap.&lt;/p&gt;</description>
    </item>
    <item>
      <title>What Is Request Coalescing and Why Duplicate Work Should Share One Result</title>
      <link>https://taskfused.com/what-is-request-coalescing-and-why-duplicate-work-should-share-one-result/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://taskfused.com/what-is-request-coalescing-and-why-duplicate-work-should-share-one-result/</guid>
      <description>&lt;p&gt;Request coalescing means that when several requests ask for the same thing at the same time, the work is done once and every one of them gets the answer. The other requests don&amp;rsquo;t queue up behind the first and repeat it. They attach to it.&lt;/p&gt;&#xA;&lt;p&gt;It sounds like a cache, and it&amp;rsquo;s related, but it works at a different moment. A cache helps after the answer exists. Coalescing helps while the answer is still being made, which is exactly when duplicates hurt most: a slow report, an expensive API call, a page that a thousand visitors hit the second it expires from the cache.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
