<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Sql on DRM HSE</title><link>https://www.drmhse.com/tags/sql/</link><description>Recent content in Sql on DRM HSE</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 07 Jun 2026 16:05:39 +0300</lastBuildDate><atom:link href="https://www.drmhse.com/tags/sql/index.xml" rel="self" type="application/rss+xml"/><item><title>Fast Rust Exposed a Race the Handler Was Hiding</title><link>https://www.drmhse.com/posts/check-then-act-race-condition/</link><pubDate>Thu, 20 Nov 2025 05:20:09 +0000</pubDate><guid>https://www.drmhse.com/posts/check-then-act-race-condition/</guid><description>&lt;p>Fast code does not forgive sloppy state changes. It exposes them.&lt;/p>
&lt;p>That is how a SAML certificate rotation feature turned into a concurrency bug. The API was written in Rust with &lt;code>axum&lt;/code>, &lt;code>SeaORM&lt;/code>, and PostgreSQL as the source of truth. The handler looked normal. The logic was easy to read.&lt;/p>
&lt;p>Under concurrent pressure, it failed immediately.&lt;/p>
&lt;p>The bug was the old one: &lt;strong>Check-Then-Act&lt;/strong>.&lt;/p>
&lt;p>Read state. Make a decision. Write new state. Somewhere between those steps, another request sneaks in and makes the decision stale.&lt;/p></description></item></channel></rss>