Henrik spent too many hours, staring at the bug, trying to understand why the 3rd party service they were interacting with wasn't behaving the way he expected. Henrik would send updates, and then try and read back the results, and the changes didn't happen. Except sometimes they did. Reads would be inconsistent. It'd work fine for weeks, and then suddenly things would go off the rails, showing values that no one from Henrik's company had put in the database.

The vendor said, "This is a problem on your side, clearly." Henrik disagreed.

So Henrik went about talking over the problem with his fellow devs, working with the 3rd party support, and building test cases which could reproduce the results reliably. It took many weeks of effort, but by the end, he was confident he could prove it was the vendor's issue.

"Hey," Henrik said, "I think these tests pretty convincingly show that it's a problem on your side. Let me know if the tests highlight anything for you."

The bug ticket vanished into the ether for many weeks. Eventually, the product owner replied. Their team had diagnosed the problem, and the root cause was that sometimes the API would get confused about record ownership and identity. It was a tricky problem to crack, but the product owner's developers had come up with a novel solution to resolve it:

Actually we could add a really unique id instead which would never get repeated, even across customers, it would stay the same for the entity and never be reused

And thus, the vendor invented primary keys and unique identifiers. Unfortunately, the vendor was not E.F. Codd, the year was not 1970, primary keys had been invented already, and in fact were well understood and widely used. But not, apparently, by this vendor.

[Advertisement] Plan Your .NET 9 Migration with Confidence
Your journey to .NET 9 is more than just one decision.Avoid migration migraines with the advice in this free guide. Download Free Guide Now!