✅ SEP 14: UUID collision checking

Status: Finished

Date: 2023-04-07
Commit: e521f96aa448b83f61e25b9f986e17456934ec15

    Implemented within the `ingest_documents()` function using a UUID prefix
    check. This will cause an abort if ever two 8 digit UUID prefixes are found to
    collide.

All my documents are christened with a unique identifier in the form of a Version 4 UUID). This is the canonical, unchangeable reference to a document and must therefore be absolutely guaranteed to be unique at all times.

The probability of UUID collisions occurring in a sufficiently random UUID implementation is vanishingly low. Still, it may be sensible to explore the possible issues that would arise from a collision and weigh that against the cost of mitigating that risk.

Further, since ✅ SEP 12: Reference documents by their URN/UUID was implemented on 2023-04-07, more and more documents will be referenced using the eight digit prefix of their UUID. This dramatically raises the risk of a collision wherever prefixes are used (though the risk remains fairly low).

Considerations

Given that I also use UUIDs to identify unpublished documents, consideration should be given to whether unpublished documents should be checked in the same way.

It should be noted though that this represents a lesser concern as any issue arising from a collision in my unpublished documents could be resolved manually without risk of changing a published resource.
RESOLVED As at 2023-04-06 it is still possible for a full UUID collision to go undetected. This would occur because the ingest_documents() function does not check for uniqueness before writing to a UUID key.