<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Testing on Shai Asher</title><link>https://slow-is-smooth.io/tags/testing/</link><description>Recent content in Testing on Shai Asher</description><generator>Hugo</generator><language>en-gb</language><lastBuildDate>Fri, 11 Sep 2026 16:35:00 +0300</lastBuildDate><atom:link href="https://slow-is-smooth.io/tags/testing/index.xml" rel="self" type="application/rss+xml"/><item><title>The retry limit that broke a Bloom filter's one promise</title><link>https://slow-is-smooth.io/blog/the-retry-limit-that-broke-a-bloom-filters-one-promise/</link><pubDate>Fri, 11 Sep 2026 16:35:00 +0300</pubDate><guid>https://slow-is-smooth.io/blog/the-retry-limit-that-broke-a-bloom-filters-one-promise/</guid><description>&lt;p&gt;A Bloom filter makes exactly one promise: once you add a key, it will never tell you the key&#10;is absent. Last November I published a compare-and-swap loop that gave up after a hundred tries,&#10;and wrote that the bit it might leave unset was an acceptable trade-off against livelock. It was&#10;a trade against nothing. While only Adds are writing, that loop cannot fail a sixty-fifth time,&#10;let alone a hundredth. The operations that really could lose an Add were somewhere else in the&#10;library, and they never retried anything.&lt;/p&gt;</description></item></channel></rss>