Skip to main content

Fire Arrow Server 2.1.6

· 2 min read
Till Gerken
Till Gerken
CTO

Fire Arrow Server 2.1.6 has been released.

  • (bugfix) Updating an externalized Binary no longer leaves it permanently unreadable through $binary-access-read

Bug Fixes​

Updating an externalized Binary made its content unreadable​

When a Binary resource's content is offloaded to external storage, the server saves the bytes and replaces the inline data with a reference to the stored object. Before 2.1.6, updating an existing externalized Binary — re-sending it with a PUT that carried different content — stored the new bytes without recording a usable reference to them. The Binary was left with neither its inline data nor a valid storage reference, so a later $binary-access-read on it failed with 400 Bad Request reporting that the resource had no data. The resource became permanently unreadable.

Only the update path was affected. A Binary that was created once and never overwritten stored and read back correctly; the problem appeared when the same Binary was re-ingested with new content. The cause was that the server generated a storage identifier when first creating externalized content, but not when replacing it on update, so the stored reference was left empty.

Starting with 2.1.6, the server generates a storage identifier on the update path as well, matching the create path. Updating an externalized Binary now keeps a valid reference to the stored content, and $binary-access-read returns the updated bytes.

To repair Binary resources that were already corrupted by an earlier version, re-send each one with a PUT (its current content) after upgrading. The update now writes a proper storage reference and restores read access; no configuration change is required. This is the update-path counterpart to the $binary-access-read read fix in 2.1.5.