So it sounds like an issue with […] handling per-spec the presence of data which you don’t use.

The trouble is, in this specific use case, the data may either be there or it may not be, depending on authorization. I’m checking specifically if the key is present to determine whether the user has access to that data (and display a toggle for that data), or if the user mustn’t see it and thus doesn’t need the toggle.

The wrong assumption was that if the key is there, then the value is not null. That assumption was invalidated by an update on the server side. Of course I could’ve checked if the value of the key is nullish. But it’s still annoying to have a breaking frontend because the backend changed how it serves its data.

Both instances are legal serialized JSON. What makes you think otherwise?

I’m sad that there are people who call themselves developers who need to be told this.

Hell, no. If I wanted to save bytes, I’d use a binary format, or just fucking zip the JSON. Looking at a request-response pair and quickly understanding the transferred data is invaluable.

try to stick with integers in a currency’s smallest unit of division

And then the marketing department comes up with products that cost 1.5ct apiece.

I wouldn’t have thought that content suitable for talesfromtechsupport would be acceptable here. As the description says,

This is a place where you can post jokes, memes, humor, etc. related to programming!

Customer support is not usually related to programming.

Somehow I can tell that this story didn’t go down in the US.

Yes, I know the field isn’t nullable in the database. I’m asking you what you are sending me, jack——

(Directed at a colleague)

the rule is flagging a false negative

false positive?

they also pay 3000$/mo for a moldy apartment