I have found a condition with ... on MirrorValue which results in an Internal Server Error.
It appears if the board contains an “orphan” mirror column. While normally if you delete a connect boards column, all connected mirror columns are deleted, it seems possible for them to not be deleted due to an error.
The mirror column, via API still returns a settings_str that points to the deleted connect boards column, it also contains board-column mappings. The API user has access to the boards pointed to.
My suspicion is that something isn’t getting cleaned up correctly under the hood as well. It doesn’t affect all items on the board. (Maybe it only affects items that were previously connected and there is some orphan connection, or the reverse, only those that were not previously connected?)
for reference this is an accounts board in monday crm, so there could be special things happening nobody knows about. The board is also reporting 84% connections used, yet no connect boards columns appear to have any connections - but the owner can see items to select on the visible connect boards columns. if the owner didn’t have access to underlying boards they’d still see the connect boards column. It is almost like there is ghost connect boards column.
Thanks. It should be easy enough for monday to fix if they want to. It just need to handle the situation correctly and when its encountered, return an empty string since it is an empty cell.
Until then at least everyone knows this is something to look for, and have the customer either delete the column or reconnect it with a connect boards column.
We’ve been getting internal server errors when accessing the Monday API since 12:10pm yesterday, with no immediately discernible cause. Not every call is affected.
Whilst I’m not sure our error is the same, this post at least gives me another option to investigate, thank you for posting your findings.
We’re still getting this error unfortunately. Our version number is 2023-10.
Is there any other information that would be helpful diagnostically or for recording?
My instinct was to re-check our query, as we had a major overhaul of our code in line with the 15th January change over from 2023-07.
The query in question is a fairly standard (I think) board-items call & works for all but 2 of our boards. This is mirrored in the dev playground - where the query silently fails(?) for those particular board ids, but is fine otherwise.