1.8 Alpha2 API Delete Widget Sometimes Does Not Work -

[cslaughter]

It seems that when trying to delete a widget via the API, sometimes it will fail for an unknown reason. If we refresh the page it then seems to work. We have no idea why this is happening. It doesn’t seem to be a specific file as we get it randomly with all video and image files. (We haven not tested anything else at the moment)

With Debug on, this is what the Log show when it happens:

177	4ca21cd	2016-02-06 23:04	API	DELETE	DEBUG		/playlist/widget/:id	Storage rollback.
176	4ca21cd	2016-02-06 23:04	API	DELETE	DEBUG		/playlist/widget/:id	Widget not found

The widgetID’s we are trying to remove, are showing in the database for Xibo. (Update: They are there, but they are not the correct ones for what we are trying to work with.) We see the widgetID up till we send it via the API.

Update: Problem identified and the issue all boiled down to this:

1.8 Alpha Api - Add Media to Region of Layout

Now that we can add media to a playlist as a widget, we need to know how to record the widget id we added so that later we can remove it from the playlist. Looking at the API response, I only see the ability to get all the widgets assigned to a playlist, after adding media to the playlist. How do we go about getting the widget id that is created when we add the media? We could pull the last “widgets” and assume that is the one, but I am not sure that will always returned the desired result.

Sometimes we don’t get the desired result.

We see that an enhancement was made, but how do we go about using the enhacement?

Add a flag to indicate whether a widget is newly added during the current save() operation.

[cslaughter]

We see that the isNew on the returned array.

[dan]

returning isNew on the response of the add call was put in place so that you could look through the widgets returned and pick out the new ones added by that call.

I can’t see how the widgetId on those elements could be different to the one that was actually saved - at the point of the return the data is actually saved…

Are you sure you are recording only the isNew ones?

[cslaughter]

We are investigating this more. The problem we are facing come from some code of ours before the isNew enhancement was made. We loop through a bunch of media adding it to multiple playlist all at once. (Sometimes 40+ media adds at once.) Somewhere in this process for us, occasionally our system records the same widgetID for different media being added. The CMS does not show any problems that we see,

We attempt to add more logging to see what is happening. More than likely we will find the problem within the code we have.

[dan]

OK great, at least you have an idea where the problem might be

[cslaughter]

We are still running into this. Our most recent test show that we added media and was returned was 332, then again we added media and was given 333, added again, 332, added again 333, again 334.

How is this possible? If a media item is assigned to multiple playlist, can it get the same widget ID? Or if media is assigned to the same playlist multiple times, can it get the same widget ID? Could this be a problem with browser cache?

[dan]

The ID is an autonumber in MySQL terms and is guaranteed to be unique for each widget. Widgets are unique on their playlists (they are direct children).

I really don’t see how you can get 332, 333, 332, 333, 334 out of 5 sequential calls. When this happens what is the actual result in the CMS database if you look at the last 5 records inserted into that table?

[cslaughter]

The records in the CMS database are correct.

We will try a different version of SQL and PHP to see if somehow that makes a difference,

[dan]

Would it be possible to capture the return body each time you make a call and log it? It would give us something to look at when trying to debug.

[cslaughter]

It appears to be something with the version of PHP we were using. Sometimes “== true” would fail and also “=== true”. We changed our code a bit and the problem is solved.