[Bug, from GitHub] null values in account settings via api.omg.lol

API
, , ,
1

Migrated from GitHub #613

Bug Description

TL;DR

The communication and date_format fields of the settings object in the JSON response to the account info API endpoint are null in some instances, which may cause breakages and unexpected behaviour on downstream clients.

The bug

Performing an authenticated GET request to the https://api.omg.lol/account/foobar@example.net/info endopoint yields a JSON thingy with loads of stuff among them, we’ve got the settings object. When I queried the API for my account this is what it showed:

"settings": { 
    "owner": "*snip*", 
    "communication": null,
    "date_format": null,
    "web_editor": "advanced"
 }

Notice the null values in communication and date_format. Note that I’ve had these values set to my personal preferences for a long time, before the move from the meta.omg.lol account console.

I went back to the web interface and just clicked the “Save Date Format” and the “Save Communication” buttons without touching the respective radio buttons and, alas, after performing the same API query one more time this was the result:

"settings": {
    "owner": "*snip*", 
    "communication": "email_ok",
    "date_format": "iso_8601",
    "web_editor": "advanced"
}

Why does this small difference even matter?

There has been an increasing amount of folks doing wrappers for api.omg.lol and/or clients for om’glol in all sorts of different languages. In some cases, usually in more type strict languages such as Rust, you should specify the expected variable type when unserializing the JSON response (and those languages usually also don’t really like null values), so if there’s an edge case in which some (not all) accounts can have a null type in one of the object fields (like it was my case), there’s a chance that this small quirk may cause a lot of downstream clients to crash when receiving this response.

There are, of course, ways to handle cases in which the response may be null, and those cases are documented in the API docs, but this seems to be a particular case in which that null is not expected to be there, so it may lead to some breakages down the line.

Steps to Reproduce

This is very tricky to reproduce. I would imagine it happens on old accounts in which those settings haven’t been changed since the backend database migration.

3 Likes
2

+1. Should be dupe of issue 591.

2 Likes
3

As you can tell, I’ve been spoiled by decades of using languages that are really forgiving about this kind of stuff. :sweat_smile:

What’s the best “universal” approach to handling the absence of data in JSON API response? Should I provide an empty string (i.e. "")? Should I omit the items entirely if there’s no data for them? Or something else?

1 Like
4

Is the data actually absent, though? My date setting was null in the API, but on the website it was set to iso_8601. In that case, I would expect the API to say it’s set to that.

1 Like
5

But for these things you can probably set defaults, right?
For instance, for the email communication afaik the GDPR has a strict consent requirement so I don’t think there’s much of a choice for communication, as for the date_format, iso_8601 seems like a sane default.

@vukky :

Is the data actually absent, though? My date setting was null in the API, but on the website it was set to iso_8601. In that case, I would expect the API to say it’s set to that.

That’s exactly what happened to me, those values were set (and I’m pretty sure they were not the default ones), and only after I went to the portal and pressed “Save” on both did the API update. Must be some artifact of the transition from the old backend.

1 Like
6

Yeah, I think you and @vukky are both correct here — there are defaults, even if the values aren’t explicitly stored, they should be reflected wherever they can be viewed (whether that’s in the application UI or in data provided via the API).

Will get this fixed as soon as I can!

2 Likes