You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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/[email protected]/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:
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:
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.
The text was updated successfully, but these errors were encountered:
Bug Description
TL;DR
The
communication
anddate_format
fields of thesettings
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 thehttps://api.omg.lol/account/[email protected]/info
endopoint yields a JSON thingy with loads of stuff among them, we've got thesettings
object. When I queried the API for my account this is what it showed:Notice the
null
values incommunication
anddate_format
. Note that I've had these values set to my personal preferences for a long time, before the move from themeta.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:
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.
The text was updated successfully, but these errors were encountered: