409s when loading board plugin data

Hi there,

We are seeing this for one of our users when they are opening their boards and our power-up tries to load their board data

/1/board/{BOARD_ID}/pluginData:1 Failed to load resource: the server responded with a status of 409 ()

The result is none of the saved data is showing up.

This doesn’t seem to be a widespread issue and could potentially be something they are doing? But because it does look like they are getting a response from trello when trying to load the pluginData I thought I’d ask here in case anyone knows what is going on.

:eyes: Digging into this now.

This is happening on a call to t.get()?

I’d expect this to happen on a call to t.set() since that is making a PUT request to /1/pluginData to update data (https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/409).

And is this only occurring when they are opening their board?

I have a sneaking suspicion that what is happening is that a capability handler is being called twice in quick succession on load (current expected :sweat:) and inside of the capability handler is a call to t.set. That second t.set is 409’ing because the first one hasn’t resolved yet and there is effectively a lock on the pluginData.

Not sure if this is only happening when they open the Board, or if it is from set or get. I will have to ask for some more details from the customer.

The underlying issue is that the board plugin data seems to be missing when we load it, meaning none of their past settings are showing up. Possibly the 409 was from them trying to set them and it being rejected? But then the question is how the board plugin data wasn’t there in the first place. I have asked for a log from when they have just opened the board to see if the 409s show up there.

Oh ok. I know what may have been happening. I had something similar reported by another Power-Up.

If a user switched to a board via the app (not by navigating to a new URL) there was a race condition where a call to t.get() from a capability handler would return before the web client had successfully hydrated itself with the pluginData for the new board. So the call to t.get() would return only the data that it had in cache (anything stored on the member/org) and the data stored on the board would be missing. Then, your Power-Up probably tried making a call to t.set() to set some of the data that was missing.

On Monday we shipped a fix to the Trello web client to reduce the likelihood of the race condition occurring.