In many companies, there's also option C - fix it yourself. Any way you slice it, the bug is in the system that's reporting the wrong condition, and adding a defensive check merely papers over an issue with additional code complexity.
Sure - your program can degrade gracefully. But that should be for informational / diagnostic purposes only. It doesn't change the fact that you're using a system that is not living up to its data contract.
To make an analogy pivoting on contracts: modern programming is often not a "rule of law" environment. If you try to pretend that it is when it's not, you're just going to get a lot of pain. And you can't fix everything by yourself.
At some point, the most efficient way to push back against bad code is by validating the contract at the boundary. Then, when that breaks, you have a lot more leverage to go around and demand fixing things.
Or, better yet, use systems that don't allow contracts to be so easily broken. Static typing is an example of that.
Sure - your program can degrade gracefully. But that should be for informational / diagnostic purposes only. It doesn't change the fact that you're using a system that is not living up to its data contract.