Hi @zweitze!

Hmm strange error.

Do you mind letting me know of your user ID that was being used to make this API call? I can then check our logs to see if I can find any more information about this incident.

Glad to hear it’s working now though!

Hi @Helen!

The user_id is 19162432, account_id is 3133580.

Thanks!

Hi @zweitze! Thanks for sharing these IDs with me.

I took a look, and I think I was able to find the request you were sending.

It seems one of the column_values you were attempting to change was to assign a user to an item, is that right?

If so, this error message then makes sense. It seems the user you were hoping to add to the item in the person column doesn’t have access to it, and thus cannot be subscribed (i.e. added).

Could this explain the error you’re seeing?

@Helen,

Thanks for getting to the bottom of this! Two columns were being updated, one was a Status column, the other was a PersonsOrTeams column. The explanation sounds plausible.

But… That same user could be set at the same column of other items in that board.

And… Applying exactly the same request (same values, same item) about ten minutes later did succeed (sorry, no logs of that request). So the error appeared to be transient.

Can you think of a reason why this error went away? My goal is to set up a retry when a column update gives a transient error. But then I must know how to recognize transient errors.

I do have another question about updating PersonsAndTeams columns, with respect to permissions: can pending users be added to those columns?

Thanks!

Hi @zweitze!

Yes you can definitely assign a pending user to a Person column.

Hmm I’m not fully sure why you may have received this transient error. I think trying to catch these errors is a fantastic idea, but may be difficult in practice since these errors can come up due to a multitude of reasons: the timing of the requests sent, particulars and events occurring on your server and then on the monday.com server.

Do you mind that these transient errors cause many issues in your workflow? If you want to give me a specific example of a case in which these errors caused a hiccup in your workflow, I’m happy to bring this up with our developers to see how we can solve it.

Thanks!

Helen,

The use case - if our software can detect that retrying has a good chance of succeeding, it would do so and nobody would know something was wrong. Now we can’t.

Generally I always investigate errors. The excessive logging is done to help those investigations.

If you say there’s not enough information to get the true origin of the problem, well that’s too bad. If more information would have helped, let me know what could help and I will try to collect that for future problems.

Thanks you!

Hi @zweitze,

Not at all! I think the information you provided was perfect, there’s nothing I would’ve changed on that front.

Apologies I think I’m missing a detail. When the request went through successfully a few minutes later, was this other request caught by our retry policy? Or did you try again manually?

For all failed requests, we do typically have a retry policy of every minute for the following 30 minutes, so I’m wondering if this error was caught by this retry policy.

Hi @Helen ,

Apologies about the delay. We ran our software again, our software detected that this item needed an update, and did update the values with success.

In case you wonder, my decision to run it again was that the error message made no sense to me, so I had the hypothesis that some other, possibly transient error happened on the Monday server - like a memory corruption. Therefore we just tried it again.

You made a remark that haunted me for the last few days:

For all failed requests, we do typically have a retry policy of every minute for the following 30 minutes

I guess this only applies to mutation requests, not query requests (how would a client receive its results?).

Anyway… Let’s say a mutation request initially fails, for the ultimate transient error: hitting a Rate limit. Are you really saying that this request is retried again and again?

More general, does this mean Monday API reports that some request failed, while it might succeed. Is this behavior described anywhere?

Thanks!

Hi @zweitze,

Got it, thank you for letting me know.

So the retry policy I mentioned is for custom endpoints (i.e. your custom actions and custom triggers). It wouldn’t apply to all API calls made. In this case, should your API query see a rate limit error, it would not be retried over and over again.

This is the article that explains our retry policy here:

I think my previous message may have been confusing, apologies! Hopefully this helps clear things up.

Hi @zweitze,

Since it’s been a while since we last heard from you, I’m going to mark a solution to this thread.

If this issue has not yet been resolved, feel free to make a comment within 7 days or start a new thread.

Thanks!

@Helen ,

The problem is still happening every now and then…

Last time was May 27, the one different thing is the function - this time update_column. I have four separate request (and response headers) of the errors, let me know if you’re interested, and which response headers you need.

When retried four hours later, no problem occurred.

I am still investigating why this happened. I have a hunch that our software attempted to update the person column with exactly the SAME value. Obviously that is some error of me, but I would think the API is usually able to handle that situation, right? Especially as the same request succeeds some time later.

But then again, maybe the API shouldn’t. After all, the documentation on People columns states:

To UPDATE a people column, send an array with the people or teams you want to ADD to the column.

(emphasizing by me)

This would mean you never change or clear the contents of the people - when using the API. Is that correct? In that case, can the documentation also say how to remove people from a person column?

Anyway I can imagine some problems when you add a person to the list that already contains that particular person. Especially since that particular column has setting “Maximum people allowed in this column” set to… 1.

Could this be a problem for the Monday API?

Hi @zweitze!

Yes I would love to see those errors if you want to send them over.

Just to make sure we’re on the same page, the error you were seeing was the same “user can’t subscribe to a pulse without being exposed to it” error, right? Or was it a different error?

In terms of adding a pre-existing user to a People column, your query should not throw any errors. The user will simply not be added (since they already exist in the People column in question), and there won’t be any changes in the UI. This should be the correct behavior you’re seeing.

While you can’t remove a specific person from a People column, you can clear the entire contents of the people column by sending an empty object in the value argument of change_column_value(), or whichever column change method you’re using. It should look like this:

This information is stored in the “Removing Column Values” section here, easy to miss!

I think our next step should be to review the errors you’re seeing. I can confirm though, that your UI should not be affected when attempting to add a pre-existing user to a People column.

Hi Helen, thanks for pointing out the section on clearing column values. Indeed I missed that!

Anyway, the errors. I have four errors from four different request, all on May 27, between 12:01:28 and 12:01:29 CEST (Central Europe, UTC-2). All API calls were:

mutation request($boardId:Int! $itemId:Int $columnId: String! $value:JSON! $createLabelsIfMissing: Boolean!) { change_column_value (board_id: $boardId, item_id: $itemId, column_id: $columnId, value: $value, create_labels_if_missing: $createLabelsIfMissing) { id }}

Most variables had the same value every time:

Even variable “$value” always was the same (I only see that now…)

{

   "personsAndTeams": a

       {

           "id": 12171537,

           "kind": "person"

       }

   ]

}

Variable “$itemId” was different for every request. I will list them along with response “x-request-id”:

Note that I do have other response headers too - just ask if they’re necessary.

The response was always the same:

{"error_code":"RecordInvalidException","status_code":422,"error_message":"Validation failed: user cant subscribe to a pulse without being exposed to it","error_data":{"error_data":"Validation failed: user cant subscribe to a pulse without being exposed to it"}}

I’m curious what you find out!

Hi @zweitze!

Do you mind giving me a more updated time frame? I’m only able to see a week back, and wasn’t able to find any relevant error messages.

It’s still the same account ID 3133580 and user ID 19162432, right?

Thanks

So it didn’t happen again until… today! (June 7, about 12:01h CEST)

This time $value was:

{

   "personsAndTeams": s

       {

           "id": 13236312,

           "kind": "person"

       }

   ]

}

Here is the list of items being set, and the corresponding request ids:

And I have about a dozen more…

I also noticed:

• These were most likely actual changes. Before the call the column had a different value, maybe an empty value.


• The request was actually executed and is logged under the item’s activity log (!)

Further, as you said it’s the same account id, same user id making the changes. And the error message was again

{"error_code":"RecordInvalidException","status_code":422,"error_message":"Validation failed: user cant subscribe to a pulse without being exposed to it","error_data":{"error_data":"Validation failed: user cant subscribe to a pulse without being exposed to it"}}

I wonder what you may find out! Thanks in advance!

Hi @zweitze!

Hmm okay, I’m seeing these errors on my end. I would love for our developers to take a look at this, in case there’s a bug.

In order for me to submit a report to them to review, I will need a little more information from you:

1. Is it still true that when this happens, your software catches the error and then retries, and the retries are successful?


2. Before, when you were seeing this error it seemed that the users were never added to the People column because of it. This past error however, did subscribe them successfully despite the error-- is that right? Do you think this could have been a result of your own software?


3. If needed, do you grant our developers permission to access the account and user ID listed above to troubleshoot?

The second question I’m especially curious about. I wonder why before the error resulted in the action not be completed, and now the action is completed despite the error message, and is even showing up in the activity log?

Thank you!

I checked a bit more. The intention was indeed to change, the previous value of the column was probably user 21132352, so not empty. The new user ( 13236312) was already used for that column on different items.

On your questions:

1. No we don’t retry failed calls yet. At one point we will, as soon as we learn which failed requests may succeed when retrying. But not now.


2. Actually we try to CHANGE the column value. The column has setting “Maximum people allowed” set at 1. And as you said, despite the error, the value was changed. Another observation: I think I looked at it at 12:15, and saw the value was not changed, then again at 15:00, and then the value was changed. At that time I wrote my previous response in this thread. Note this observation at 12.15 is very sketchy, no screenshots or anything. About the activity log: it does not mention something failed, only that the change did happen.


3. Checking our board - no problem as long as they’re with Monday, we assume the same integrity as the system operators, and we do trust the same data to you already. They may want to change values - ask again if necessary because this is production data. Plus, every four hours we update the board to the last values of our internal enterprise software. I will give different item IDs that are likely similar, but will be ignored by our software.

Hi @zweitze!

Thank you for this, I just posted this for our developers to take a look and give us some more info. I’ll let you know what they say once they get back to me.

Hi @zweitze!

Our devs took a look and let us know that user 13236312 is actually not subscribed to private board 1207052136 which seems to be the cause of the error message you saw.

The transient behavior is indeed strange though. I’m curious how this user was later added successfully? Could it be that someone then subscribed them to the board?

Is the board ID indeed 1207052136? Or is there another board in question?

Hi @zweitze!

As a heads up, we generally close our threads if we don’t hear back within 2 weeks or so.

If this issue comes up again, feel free to write into appsupport@monday.com.

Thanks~

Helen,

Sorry about the delay - I enjoyed a holiday. This issue last showed up on June 15.

Further, the board ID is indeed 1207052136. User 13236312 at least has a valid login to our account, the ID was even retrieved with a query to retrieve users. And I am 99% certain that this user was already subscribed to different IDs in that board. And nobody else did the job instead.

The Edit permissions of the board is set to:

“Edit content only in items assigned to them in the user or columns”.

Maybe this is a clue? That particular user did not have edit permission, as he was not assigned before. Then again, the API was not called on behalf of that user, but on behalf of a Board owner.

Do you have other suggestions for logging?

Thanks!

Hi @zweitze,

Thanks for the update!

The issue the developer let me know of is that the user is not subscribed to that particular board. Since it’s been a few weeks, I’m asking him to double check if this is still the case.

Do you mind giving me the URL (I need the item ID) of an item where the user was successfully subscribed to on this board?

Thanks~

Hi @zweitze,

Just an update: our developer checked again and he confirms user 13236312 is not subscribed to board 1207052136.

Once the user has been subscribed these errors should go away.

Hi Helen,

So I did find some items for the same user, that were created earlier, without any problem. For instance:

/boards/1207052136/pulses/1248520129

/boards/1207052136/pulses/1248520205

/boards/1207052136/pulses/1248520238

Activity log of those items state they were created two months ago, and after that the person column was never changed.

But the developer may have a point. Maybe this user got annoyed by all notifications, tried to fix it, and accidentally unsubscribed himself. Is that a valid hypothesis?

(In the board log I could not find evidence of this, but maybe subscription changes are not logged.)

I must say I never thought of this possibility - after all, you can enter any user in the regular UI, without any warning when entering an unsubscribed user. Documentation gave no such hints either.

Still, when you want to update a People column, does that mean you have to check the boards subscribers first, and if necessary add the user to the board subscribers? And the regular UI does all that on the background?

Thanks in advance!

Hi @zweitze,

That does sound like a valid hypothesis, however subscription and unsubscription changes are indeed logged in the board’s activity log!

Re your question: this only applies to Private and Shareable Boards, but yes, unless a user is subscribed to a Private or Shareable board, they cannot be added to any People columns. This is a permissions feature that’s enforced by the platform.

In this case, since the board is Private you will need to query the board subscribers first before adding the relevant user to a People column!

I’m going to mark my previous post as the solution since we have found that this is not a bug-related issue.