v2.4.7

HexDB 2.4.7 fixes two problems found after 2.4.6: uploads could lose their content despite replication.min_acks, and hexes started at the same moment could both lead.

Fixed

• min_acks covers uploaded files' content. A replica acknowledged an upload once it had applied the file's document, but it copies the file's content afterwards, in the background. If the Overseer failed between the two, an upload acknowledged as replicated could lose its content. A replica now also tracks how far it holds the content of the files it applied, and reports it to the Overseer. A write to a files tessellation counts a replica only once that position has reached it, so with min_acks set, an acknowledged upload's content is on that many replicas.
• Hexes started together settle on one Overseer. At startup, of two hexes claiming the Overseer role, the one whose discovery listener started first keeps it. The times were compared in milliseconds with ties broken by ID, so two hexes that started listening in the same millisecond could both keep the role until the next discovery round. Hexes now report the time to the nanosecond.

Upgrading

Restart the hexes one at a time, as usual: replicas first, the Overseer last. Replicas running 2.4.6 or earlier don't report a content position, so until they're upgraded they count as acknowledging an upload the way they did before. Coming from 2.4.5 or earlier, read the 2.4.6 notes first: they include security fixes.

Full Changelog: v2.4.6...v2.4.7