Skip to main content

Hi,


I’m observing some real strange behaviour as part of a custom Monday integration we have created for internal use. We"re using the V2 API to write group and items onto a board.


Let me outline the architecture first:



  1. Read data from Monday board X and aggregate that data into an object

  2. Put the aggregated object on a queue

  3. Read the aggregated object from the queue and for each item from the queue do the following

    3a. Create a Group

    3b. Insert items into that group


What we notice is that in some cases, the create group mutation is executed, you briefly see the group appearing on the Monday board. We even get a group id for the created item (it’s november46256 for example). But once we try to insert items into the group, the group suddenly no longer exists. When refreshing the Monday board, the group indeed just ‘disappears’.


I cannot consistantly reproduce this, sometimes it works flawlessly, sometimes it doesn’t.


Is there any transactional concept on a mutation that we need to be aware of? Anyone got any idea what might be causing this?

Hey there @JorneD :wave;


Thank you for such an awesome post - the detail and structure really helps us tackle this as efficiently as possible for you.


To be transparent here, I have seen other users report a similar issue and it was mostly related to the number of API actions they would run in a short timeframe. When running multiple API calls within a short time window, there will be a conflict in the race condition and thus, some of the values will be rolled back.


In most cases, adding a timeout between your API calls did the trick for our users, as this helped reduce the overall volume of API calls in a short timespan. Do you think that could do the trick here?


-Alex

Hi @AlexSavchuk ,


Thanks for the quick reply. That sure sounds like quite a plausible cause. I’ll add some delay and see what happens.


Looking at the bigger picture: isn’t this something your API should be able to cope with? In my case it would be easily solved if I would have either of two options:



  • Create groups with items underneath as part of a single mutation

  • Delete items in bulk (then I could modify the overall architecture)

@JorneD


Thank you for getting back to me and I am keeping my fingers crossed that things work well after adding a delay 🙂


I’ll check on that with the dev team, but in my understanding, we provide our API as a way to pull data and push (mutate) data on your Monday.com account, and I don’t think there is a way to accomplish certain tasks with a “batch” call. That said, I do agree it would make your life as a developer much easier, so I’ll raise that with the product team to see if we can make some improvements here.


-Alex

Hi @JorneD, I’m a developer in the team.

I’ve deployed today a fix that should resolve your issue. please let me know if it’s still happening.



  • Yoav.

Hi @Yoav_Amir , I resolved it by making certain the processes only runs a single thread at a time (it is deployed on an AWS Lambda which launches multiple instances at the same time by default). I will remove the concurrency limit and try again. Will keep you posted.

Hi @Yoav_Amir, after removing my concurrency limit, I’m still tasing the same issue. A group created within a single thread seems to not exist when inserting items in that group within the same thread.


Any logs I could provide that could help you finding the root cause?

Hi @JorneD, waiting to hear from you, did you manage to solve it ?

Hi @Yoav_Amir, nope still facing the same issue from time to time. Is there any logs/details I could provide that could help you guys in finding the root cause?

Terms & ConditionsCookie settings