Attempt to change column values, get an error about pulse subscription

With the following command:

mutation request($boardId:Int! $itemId:Int $columnValues:JSON! $createLabelsIfMissing:Boolean!) { change_multiple_column_values (board_id: $boardId, item_id: $itemId, column_values: $columnValues, create_labels_if_missing: $createLabelsIfMissing) { id }}

-and valid values-

I got the following response:

{“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”}}

In other words, a message about subscribing to a pulse, while the request was to change multiple column values. How do I deal with such error messages?
I recorded the response headers, here is a selection:

Name Value
Transfer-Encoding [ “chunked” ]
Connection [ “keep-alive” ]
x-request-id [ “832ffcbd-d134-9f8c-ad90-b86c1ea1cdb1” ]
x-runtime [ “0.222076” ]
x-envoy-upstream-service-time [ “229” ]
x-monday-rgn [ “use1” ]
CF-Cache-Status [ “DYNAMIC” ]
cf-request-id [ “09f8415779000001112b2b2000000001” ]
Expect-CT [ “max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\”" ]
CF-RAY [ “64d3d19f2d8e0111-AMS” ]
Date [ “Mon, 10 May 2021 14:22:17 GMT” ]
Server [ “cloudflare” ]

I tried the same request a few minutes later and go no error anymore. But why was this error returned the first time?

Thank for your insights!

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:

Variable name Value
$boardId 1207052136
$columnId user
$createLabelsIfMissing true

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

{
   "personsAndTeams": [
       {
           "id": 12171537,
           "kind": "person"
       }
   ]
}

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

$itemId x-request-id
1314456151 1b4cb0e4-6817-90d6-8ee0-5f09f5d1d616
1302242019 73686c4c-820a-9979-88b9-3ab255700e49
1302242003 2334b0c4-bc82-97d4-b41c-1960d38cef65
1302241988 8385671f-fbf9-9787-ac30-fc70fa15ceb6

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": [
       {
           "id": 13236312,
           "kind": "person"
       }
   ]
}

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

$itemId x-request-id
1348054546 45931962-51a6-9074-bdb8-96ad8348fb53
1348054512 bd47b943-93be-9cb4-adc3-2eb57a990f59
1348054505 105375cf-7708-9b1c-9404-43f3196a12bd
1348054497 21d59616-5e71-9b82-ae29-189e9e876126
1348050128 34c70cc8-c5cd-984d-9371-c8f99d107790
1348050099 9743b760-63e2-9944-ab9e-4e2cb617db1d
1348050083 36e30183-5479-9539-88fa-844ca09bbcfb
1314455799 386690cc-7aef-9446-9728-6a9dc4d4a386
1302233885 8cca20b1-9687-938f-b8e4-d195c2cb94d4
1302233824 f145a23d-6ae0-9767-81c4-e481b4aa2ab0

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?