New Column Creation Bug

monday Apps & Developers Feature Requests - API and Apps Framework
, , ,
1

Currently facing an error whereby some columns created don’t appear on the board and fail when their returned ids are used.
For example, in the image below, the mutation returns the ids of the created columns. One of such ids is the last_order9 id.
image

This column doesn’t appear on the board even after refreshing the page. Now, when I try to use the returned column id in another processing, it throws an error saying that, the column id does not exist

image
image1035×19 2.04 KB

This is related to a bigger problem that is, some columns created do not appear on the board and those that appear often need a browser refresh to see them. I already mentioned this problem here.

Secondly, to the best of my knowledge, there is no way to create other column types apart from the status column from the documentation. In the create a column (Columns) part of the documentation, the example only shows how to create a status column. In the respective documentation for all the other columns, they all talk about how to update a column but never on how to create them. The example of the status column mentioned above isn’t applicable to the other columns because, as I later found out the hard way, the result received when one queries for the column type is different from what is needed to create a column. Though some may be similar, others are absolutely different so the requests fail. An example of such is the people column. When one queries the type for that column, it returns multiple-person but to create such a column, you have to send the ColumnType of people. status and color is another example.
Could you please provide the various mapping between the ColumnType and type needed to create a column since they are not in the documentation? For example,

{
color: "status",
"multiple-person":"people"
}

Thank you.

2

hi @kolaai

I don’t know where the first screenshot came from, is that Postman or the API Playground? I see from that screenshot that you are trying to create a date column. The correct syntax is:

mutation {
    create_column (board_id: 1234567, title: "My Date", column_type: date) {
        id
    }
}

The column_type is not a string “date” in your screenshot but a ColumnType, of which date (without quotes) is a valid one. With this you can create any column you need.

3

Hello @basdebruin, the first screenshot is the result of a successfully run query, which is a date column. I added the screenshot to show that, but mutation runs successfully and returns the respective created column ids but the columns are not created, both visibly on the board and also when trying to use the returned “created” column id, it throws an error that the column does not exist.

4

If you run the above mutation in the API Playground, doesn’t it create the date column?

You are correct: there is a difference between the types you need to specify and the types being returned. The ones I am aware of are:
status = color
timeline = timerange
people = multiple-person
time_tracking = duration
numbers = numeric

And I am sure there are others :slight_smile:

5

For single column creation, like the example you provided, it works (even though I have to refresh the browser before seeing the created column). For multiple columns, that is where it fails. In the screenshot, you can see that, the array contains 5 objects. That is the result of 5 columns that is supposed to created. Out of the 5, it creates like 2 or 3 instead of 5, but in the returned results, it shows that, it created 5 columns. Hope this clarifies the issue.

7

Hi @kolaai,

Thank you for sharing your feedback! I can absolutely empathize with how confusing it can be that the column type requirements do not match the types returned when querying columns.

While we don’t have a list on hand, I would be more than happy to let our team know to compile one and put it in our documentation for future reference!

Regarding the successful responses, this is actually something that I have heard of before as well. I believe this issue happens because the columns are created in quick succession. This could lead to requests “running into” each other and thus some do not get created. In cases such as these I do recommend creating these columns in a more spaced out fashion.

Are you still having trouble creating your date column? Or is it working say if you create one in our Developer’s Playground area?

8

Hello @Helen,
Thank you for your response.
Unfortunately, the problem with your suggestion is that, there is no guarantee that, the columns will be created even if they are run in a “more spaced out fashion”. How much spacing is advisable and what is the guarantee that, they would still be created with the provided spacing. I think what we are trying to do here is clearly a workaround for something that is clearly a bug. I create items in the same fashion and they work perfectly without any spacing.


Another problem with your suggestion is that, using ‘spacing’ can quickly result in timeouts when these columns are created through an integration. When running integrations, every second matters since backend service in use have timeouts. This is exactly the reason why I have been requesting for a column deletion because clearing existing ones is a very expensive and time consuming process.


monday.com main feature and single truth of source is the board, which fundamentally consists of rows and columns. If we can’t create columns in the same fashion in how we can create rows, which by the way, has way less limit than the latter (that is, the max number of rows is in the tens of thousands and for columns, in the hundreds), then I think we can both agree that, there is a problem.

To reiterate, I don’t have a problem with creating a date column, I have a problem with creating multiple columns.

9

Hi @kolaai,

Thanks for letting me know. I can understand your frustration here, but I hope you trust that we’re here to help, and do not take any of your feedback lightly.

I’m in conversation with our team now about how to fix this issue. One of my devs is investigating, and is wondering if you can send us your full mutation method code in creating these columns from an array. Can you send us the full response that you’re getting as well?

Thank you!

10

Hello @Helen,
Thank you for response.
My comment was in no way to undermine the effort you are putting it to resolve the situation. Not at all. I was just stating the possible challenges I would face should I go on that route. This is because, the very response that indicates a completed request is being sent even though the columns are not created. That is worrying because, one then has no way of knowing whether all not the columns were created or the response was sent without creation.


Now to the code in question,

const newColumns = newCols.map((column) =>
                  createColumn(boardId, column.title, column.type)
                );
return Promise.all(newColumns)
                  .then((data) => {
                    console.log(data);
                  })

The logged data returned is:

[
    {
        "data": {
            "create_column": {
                "id": "last_order5",
                "title": "Last order",
                "type": "date"
            }
        },
        "account_id": 7845898
    },
    {
        "data": {
            "create_column": {
                "id": "owner",
                "title": "Owner",
                "type": "multiple-person"
            }
        },
        "account_id": 7845898
    },
    {
        "data": {
            "create_column": {
                "id": "priority",
                "title": "Priority",
                "type": "color"
            }
        },
        "account_id": 7845898
    },
    {
        "data": {
            "create_column": {
                "id": "qty",
                "title": "QTY",
                "type": "numeric"
            }
        },
        "account_id": 7845898
    },
    {
        "data": {
            "create_column": {
                "id": "price",
                "title": "Price",
                "type": "numeric"
            }
        },
        "account_id": 7845898
    }
]

Now when I try to use the returned created columns id in my next processing, I get an error because even though the response says they were created, they weren’t. Out of the 5, only 2 were created, that is Last order and Priority.
This is evident in the error that I received when I try to use the Owner column.
Below is the error message.

There was an error in response from monday.com graphql API:  {"column_id":"owner","error_reason":"store.monday.automation.error.missing_column"}

As you can see, even though Owner column was created as indicated in the response, it wasn’t and therefore results in an error.
Hope this clarifies things.
Thank you.

12

No of course not @kolaai, I can absolutely understand where you’re coming from and how worrisome this behavior would be.

I just sent this information over to our developer to continue investigating this. I’ll let you know as soon as he gets back to me!

13

Alright. Thank you once again for your help. You are doing a great job :slight_smile:

1 Like
14

Hi @kolaai,

Coming back to you with an update from our dev!

He was able to take a look and let me know that currently, our create_column() endpoint is not built to support the creation of multiple columns at once. This means that the last few requests you’re sending “override” the data of the first few requests and as a result, only some of the columns are created.

To resolve this issue, our team is currently conversing about potentially creating a new method dedicated solely to the creation of multiple columns at once.

For now, the dev suggests a few alternatives for your requests:

  1. bluebirdjs’s - Promise.each
  2. bluebirdjs’s - Promise.map (with concurrency 1)
  3. Iterate on your promises and await each of them separately

Try these out and let me know if they help at all. I’m also going to move your request to the Feature Requests section, since this area of our platform can be greatly improved. Thank you for bringing this to our attention!

16

Hello @Helen,
Thank you for your message. I had already tried and implemented the last option after I first noticed the problem. I hoped there was a way to support multiple columns at once since that was faster. Now that I know that, there is no concurrency support at the moment, I’ll have to continue with the current sequential implementation until concurrency is supported. Thanks once again.

1 Like