Board IDs are now too big for an integer! Check your databases and update your apps :)

monday Apps & Developers Announcements
1

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.

1 Like
2

Many thanks for the info.

1 Like
3

Are updates affected by this as well?

4

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.:

const query = ``mutation change_column_value($boardId: Int!, $itemId: Int!, ...

(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.

Thanks.

1 Like
5

Is there to be no response to this?

When will documentation and example code be updated to reflect these changes?

For example, board Ids are ints here:

Presumably the quickstart-integrations example no longer works.

Thanks

6

Hey @adrian_crossan – sorry for the late response here.

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.

1 Like
7

OK, thanks, I’m looking forward to it.

8

Hey @adrian_crossan, the bug you reported earlier has been fixed.

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.

9

OK, good to know. Our Integration is still working.

Thanks.

1 Like
10

Hi there,
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 – GraphQL Tools 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:

// Get an executable schema as per this doc: https://www.graphql-tools.com/docs/remote-schemas
const executor: AsyncExecutor = async ({ document, variables, context }) => {
  const query = print(document)
  const fetchResult = await fetch(process.env.MONDAY_URL, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': process.env.MONDAY_TOKEN
    },
    body: JSON.stringify({ query, variables })
  })
  return fetchResult.json()
}

let mondaySchema = null;

export const getMondaySchema = async () => {
  if (mondaySchema != null) {
    return mondaySchema
  }

  const schema = wrapSchema({
    schema: await introspectSchema(executor),
    executor
  })
  mondaySchema = schema
  return schema
}

Then, to use it, just call the delegateToSchema function:

const mondaySchema = await getMondaySchema();
    const mondayRes = delegateToSchema({
      schema: mondaySchema,
      operation: 'query',
      fieldName: 'items',
      args: {
        ids: requestIds,
      },
      context: _context,
      info: _info,
    });

The documentation can be found here: Schema Delegation – GraphQL Tools

Thanks,
Carlos

1 Like
11

Hi, I’m just piggybacking on this thread to ask a related question:

I’m receiving board IDs and item IDs as strings from monday, and possibly others that I’ll discover as I go through my code to clean up types, and monday wants them as numbers in my requests. I’m storing these as numbers in my database. I’m casting these in my Typescript as I need to but I’d like to make things as consistent as possible so I need to decide if I 'm going to handle these IDs as strings or ints. I’d prefer ints but want to make sure the type that mutations require wont change to string sometime in the future.

12

Hello @Janssen,

I can not assure this won’t ever change but as far as I can see, we do not have any plans of changing this in the nearest future.

If we change this, we will let you guys know in advance in our changelog.

Let me know if you have any other questions :slightly_smiling_face:

Cheers,
Matias

1 Like