Two different Officers share the same appointments link

I’ve found a worrying inconsistency in the database. If you look at the Officers list of 80 Claverton Street Limited, one of them is the late Selwyn Charles Cornelius-Wheeler:

But if you click on his link, then you get taken to a list of appointments for:
Wilfrid Ireland Jeffrey WALSH, a completely different person:
This shows one other directorship, at The Heritage (Lytham) Limited (02634813). The Officer list of that company shows Mr Walsh.
The director appointment strings should be unique for each person, but in this case it seems that “b0_8v7CiAEiyPBJBGPOyRzzNsL4” has been assigned to 2 different people. How could that happen?

Thank you for reporting this.
I will pass these details onto the relevant team for investigation.

Thanks Mark. Do let us know the outcome, because I think a lot of API users have been working on the assumption of unique link-strings.

Now I am wondering how many other pairs of shared links there are. The strings have 162 bits (27 characters each of 6 bits) of entropy, so that is about 5.84*10^48 possible strings. The odds of a random collision are vanishingly low if the strings are pseudo-randomly generated. In any case, they should be generated and then checked against the existing list to avoid that. I am wondering if your algorithm involves some sort of hashing routine?

In this example, the underlying documents show Mr Walsh as a director of The Heritage and Mr Cornelius-Wheeler as a director of 80 Claverton Street. Neither is a director of the other company. Perhaps by coincidence, both were born in 1923 but in different months: Mr Walsh in December and Mr Cornelius-Wheeler in March.

In the search page of your web site, a search for Mr Cornelius-Wheeler’s name brings up the top match of Mr Walsh:

Thanks again. Very worrying.

Thanks again for taking the time to report this.
I will report back when I have more information or it gets fixed.

Just to let you know that this has been investigated and confirmed as a data issue.
This has now been assigned to an analyst for fixing.
I will keep you informed.

Thanks for the update Mark. We really need to understand how this happened in order to know whether there could be similar instances caused by the same process.

Just to let you know that the data has been fixed. This was only a data issue on the CHS/API service due to a failure in the update process and a manual ‘fix’ that ‘broke’ it.
This was a one off by the looks of it.
Thanks you again for reporting this, much appreciated.