Internal server error when trying to update status column

[freek-gcompany]

Hi all,

I’m having some strange behaviour in a rather simple integration recipe I’m building. The recipe is as follows: “When status changes to a value and another column is empty, change another status to this value”.
I’m using the standard trigger when a status changes.
I’ve built the following custom action:

In my code, I’m doing a simple check by retrieving the value of emptyColumnId and if it’s indeed empty, I’m changing the value of statusColumnId to statusColumnValue. However, that last update triggers the internal server error without further details.
If I log my query variables to the console and paste it in the API playground it works correctly.

What am I overlooking here?

@Helen Since you were able to help me a lot last time, perhaps you can have a look here as well?

[Helen]

Hi @freek-gcompany! I’m more than happy to help .

Do you mind posting screenshots of the internal server error message your’e seeing? Strange that it’s working in your API playground but not in your code…

When you say “that last update triggers the internal server error,” are you referring to the update of changing the second status column to a value should the column value be null? Or a different update/change?

It would also help to see a screenshot or video of the API Playground test/mutations you’re making.

Thanks!

[freek-gcompany]

Hi @Helen Here’s some of the information.
This is the query on the API playground and the result when executing it:

Here’s the code that’s generating the error:

FYI, I’m using this code in other places to update column values as well and it’s working nicely, so my feeling is that it’s related to the fact that I’m updating a status column (which I haven’t done in other places with this piece of code).
As you can see, I’m pushing information to the console, the logs of which you can find here:

Hope this helps! Thanks so much for looking into this together with me!

[Helen]

Hi @freek-gcompany!

I took a look at our logs and saw the following error messages:

"message" : "InvalidColumnIdException"

"error_data" : { "error_reason" : "store.monday.automation.error.missing_column" , "column_id" : ""

These were the variables received:

"graphql_variables" : "{\"boardId\"=>xxx, \"itemId\"=>xxx, \"columnId\"=>\"\", \"value\"=>\"{\\\"label\\\":\\\"DEMANDE CONVERSION\\\"}\"}"

I’m not sure what “DEMANDE CONVERSION” means, but perhaps this is where the issue is lying? What does your value variable look like?

[freek-gcompany]

Hi @Helen Are you sure these are the right logs? The “demande conversion” is a column I use in boards for a different customer but should not be impacted here.
My value variable is shown in the screenshot, it contains {“index”: 2}.

[dipro]

Hey Freek,

I noticed that you’re sending the value as an object, when it should be a string (ie, should start and end in quotes and all inner quotes should be escaped).

Try running JSON.stringify on the status value before sending it to us – it should result in a string that looks something like this: "{\"index\" : 2}"

Let me know if that works!

[freek-gcompany]

Hi @dipro Thanks for jumping in here! I was already doing what you mentioned but it did help me find the right solution anyways.

The “value” argument within this function was already a “JSON-stringified” version of the argument that’s returned by the trigger, but if I just added another line of converting the value to a string by doing value = value.toString() it actually works!
I’m actually rather puzzled by this outcome, do you know why this helps?

Anyway, the most important thing is that I’m no longer blocked at least!

Many thanks to both of you for your help.

Regards,

Freek

[TMNXT-Dev]

Hey @freek-gcompany ,

that’s the thing with JavaScript. It’s looks like a string, but JavaScript handles the “value” as an object.
By converting toString() you confirm that it’s an actual string.

The best way of dealing with it is either checking the types before sending to the Monday API or, what I do, use TypeScript, which protects you from occasions like that.

This is an example I did some weeks ago:

Generally speaking, if you every see a 500, you can assume to 90%, your query is wrong. I learned that the hard way

Greetings