Small but satisfying fix shipped today. Worth writing up because the root cause is the kind of bug that's easy to misread as a client-side problem.
*What developers were seeing
*
During React Fast Refresh edits, Ionify would sometimes flash an Ionify Build Error overlay — even when the source edit was valid and the change was already visible in the UI. Confusing, because the build wasn't actually broken.
What was actually happening
The HMR server was treating each queued update as single-consumer state. The moment a client hit /apply for a given update ID, the server consumed and deleted that update.
In practice this meant: if multiple clients were connected, if an apply was attempted more than once, or if refresh timing raced against the same update ID — any attempt after the first would receive 404 Update not found. The client had no way to distinguish that from a real build failure, so it surfaced the error overlay.
The edit was fine. The UI had already updated. But the overlay said otherwise.
The fix
Pending HMR updates are now kept reusable for a short TTL instead of being deleted on first apply. Updates expire by age to keep memory bounded — so you don't accumulate stale state indefinitely, but valid late-arriving apply attempts no longer hit a 404.
Full issue and diff: https://github.com/ionifyjs/ionify/issues/2
Top comments (0)