A DM landed. That’s the whole reason this post exists.
Thank you for the work, Radu. You basically saved my life. It is an edge case that I think would have never happened… until it would have. I would have been on the hook for the sum of 0.2% of depositors across both-sided pools.
— Rapha-btc , author of jing-contracts-v3 ; the case is written up in the project’s Rendezvous test notes .
Read that last line again. Not a unit test that went red. Real money, both sides of the pools, that would have walked out the door. The edge case that “would never happen” - until it would have.
So I built a place to keep these: Rendezvous PR #259 .
A trophy case. Bugs Rendezvous caught before production did. Receipts.
If Rendezvous saved you a bad day - submit yours. The case is open. The whole point is to show, in public, what didn’t make it to mainnet.
Rendezvous helps you not lose money in prod, and it makes you discover the ugly things fast - even while you’re still just testing.
That’s how the edge case above surfaced. Discovered with Rendezvous v1.0.0-rc1.
And it doesn’t stop at fresh contracts. With the simnet remote data feature Rendezvous accepts, you can point it at your already-deployed contract version and ask the uncomfortable question: from this specific block height, what can actually happen to it? Mainnet state, real history, fuzzed forward.
Rendezvous V1 is just around the corner. More on that in a future post.
Got a trophy? The case is here.