Today we hit a big milestone – board IDs in our platform became larger than 2147483647! Our users are creating more boards and workflows than ever!
However, this comes with an issue: board IDs cannot be stored as integers anymore. More specifically, they are larger than the largest 32-bit signed int.
If you are currently handling board IDs in your application as integers, you need to update your application to use another data type such as bigInt. You will also need to run migrations on any databases that store board IDs as integers, as they will fail to store any new board IDs.
EDIT: Item IDs are also affected by this! As a best practice, please update all IDs to bigInt.
Our Integrations are affected by this. We are now receiving a string value for our current board ids (int values < 2^32), which is fair enough. However, we are having to parse this to an Int before submitting the update, as the graphql mutation query insists the type is still Int, e.g.:
(The item Id is still a js Number, by the way, so we might have to convert it from a string at some point.)
Presumably if this were to run against a new board, the mutation would fail as the type for the board Id should be ID. Is this correct? If so, are there plans to make the API consistent for old and new boards? We are simply passing the board Id through as an immutable token and don’t want to worry about what its actual value might be, and avoid choosing slightly different mutation queries to post.
Our resolvers still handle IDs the same way, so queries that use integers larger than 2^32 will still work.
However, we have a known issue where variables cannot be converted from string to integer, and our team is working on a fix. You’ll see an error if you pass a large board ID as a variable. The short-term solution is to put these values directly in the query (ie, using string interpolation).
I’ll circle back on this thread when we have an update on this issue; and will update the documentation once we have a path forward.
I originally misinterpreted the root cause of the bug. The bug was that board IDs were being sent from our webhooks and apps framework endpoints as strings, which caused issues if you tried using these strings in API calls.
We now will send board IDs as integers (not strings) from webhooks and app , which means that sending large board IDs via variables now works, as does the quickstart integration guide. Let us know on this thread if you’re still having issues.
I’m facing this issue in a different context - I’m developing a backend that delegates some queries to Monday, so I was going to use Remote schemas for delegation.
The problem is that this tools has built-in scalar validation, and correctly throws an error when it finds an Int larger than 4 bytes, for example for the ids argument in the items query.
How can I make this work? To me it seems Monday API is ‘hacking’ the graphql specification to suit their needs - which is legitimate but needs to be worked out in the long term.
Is there a way to make it work?
To reproduce, we need first to retrieve the executable schema from Monday: