Server Response ETAG mismatch clientRequestId serviceRequestId

[Anonymous]

Hi,

This issue has only happened since last week. I have two sharepoint lists (lets call them list A and list B) that the app updates. When the users click on button to send email for notification the app updates list B but does not update list A and get the attached error messages. No changes were done to the app and this issue suddenly appeared. I have already tried solutions on the boards like changing the formula First for Lookup, re-connecting to the SP list.

I went into Edit mode and only used the code to patch to list and was working ok, so then I told users to start using it again but it keeps coming up with the error attached. The ids change every error message.

The frustrating thing is that there are other buttons that update list A and there is no issue with them, it is only this particular code which updates customer names, approval status, approver and value that is not working and hence app can no longer be used.

[Reza]

Greate. I will digg into to see if I can find the root cause. In the meantime, was it any reason you used Patch instead of collect function? Collect function can be used on datasources. 

[tbrantley]

@mrdang@Reza

I'm setting the Form's item directly to what's selected in the gallery. Should I do this differently? I need to get this app working asap!

[skylitedave]

I want to repost the issue that I posted a month ago on this thread.  This issue is not resolved.

I found a pattern easy to reproduce

I republished the app and an item will save fine on the first edit and save but you will get this the second time you edit and try to save.

This is very consistant an easy to reproduce. 

Open item and edit and save - no problem.  Open another list item and save - no problem.  Go back to first item and try and save - you get the error.  Go to the second item that you edited and try and edit and you get the same error.

UPDATE - If you refresh the browser before you try editing the item for a second time in a session, then you will not get an error.

Would be happy to get on a shared session to show the team...

Data Connectors are to SharePoint Lists

[tbrantley]

@skylitedave@Reza@mrdang

This is the same issue I'm having.

Works fine when creating a new item and saving it to a sharepoint list. When selecting an item from the gallery and editing that entry is when the error occurs.

[PaulD1]

I'm also getting this error intermittently (at least in the designer, haven't tested in Play mode).

It is happening for me on a simple Patch command. It will work for a while, then break and the only way to start patching to the same SharePoint list again is to close and reopen the app.

[skylitedave]

Are you using PowerApps as a detail form behind a SharePoint list? 

If so,  I think the pattern to get the error is editing the same sharepoint item more than once in a session... It will work te first time but break the second time you try and edit and save the same item in the same session. See if that is the pattern you are experiencing. If so, please confirm here so the team know what to look for.

I have found that if I refresh the browser when I am in the SharePoint  list view and then try and edit for a second time in the same session then I dont get the error...  Let me know if that works for you as well.  

[Anonymous]

I'd like to provide some additional details for my scenario as I've tried and tried to work around the issue but I still see it sporadically. Like others have mentioned, my form is one that is tied to a SP list. The form starts with a user creating a SP item and then edits the item several times within each session. When an item is created we have a separate tool that calculates information and updates the list item. Then based on that, the user updates the item again. This can happen several times within each session but at the very least it is designed to be edited at least 4 times after it is created. I know this sounds cumbersome (and it's been quite the chore to design) but the end experience provides what has been requested. I also never ran into the ETAG issue until others started seeing it as well. Even though there is another source editing the item, the form is built to be refreshed until our internal tool has completed updating the item, so the user could never update an item that is still being edited (which is happening systematically and is nearly instantaneous).

I've used the refresh workaround and built in timers to give extra time between user updates, but the issue still happens occassionally. I'd obviously like to eliminate it outright so if there is any more information I can provide, please let me know. Thank you.

[SmartMeter]

Please be patient with Microsoft folks, we did a debug session over Skype yesterday and it is very likely that ancillary updates to the list items (via flow in my case) are interfering with the "record locking" mechanism of the list items. Refreshes and such techniques are duct tape solutions, since the scheduled updates and concurrent updates all flip the version currency bit on the list item (the ETAG #) I am hoping to get some info very soon on this testing from the mothership , and we will test it out asap. I will post the findings, but Microsoft will probably beat me to it since they seem to have at least 3 people working on our problem. Thank you all for the VERY good diagnostic information, particularly in the (correct) perception that multiple concurrent updates to the list item are at the core of the issue. These guys are good, and I can commend their ability to debug, swap in and out code bases, and test this item for us. Keep up the input, but please be patient, they are good peeps who know we need it (my meeting is in 2 days with my patient but unhappy client.) Fingers crossed, SmartMeter

[SmartMeter]

Today's the day folks, just got off a debug session with the mothership, and I have tested in my app to success.  The nature of the issue is an optimistic locking mechanism that they use to keep multiple concurrent updates from hammering the list item and resulting in a fractured record. PowerApps does this by using a binary check for "stale or current" list item status with an indicator byte called this evil "ETAG". When the error trips, it is because you are trying to update a stale version of the list item. Since we users have millions of ways to do this, I will share my scenario, but yours will likely be different. I have a flow that sends outlook emails when a task is assigned to a person. This is a rogue unpredictable visitation of my list item, as soon as the people picker data is submitted or saved from SharePoint or from the app. It could also happen two minutes later!  The flow is changing the ETAG of the list item, when it dances on it for whatever reason. It is logically triggered on list item create, and it notifies the worker of their duty asap as it should. So deep within my app I let the operator look at a main work ticket and patch in a child record to a list. (No worries, if you are using only one list, same thing can happen.) Now if anything or anyone else edits your list item between the time it was patched into being in my case, and the time of your current edit session, this will happen. So microsoft has this fine lock mechanism in power apps to keep us from messing our diapers, and it is a good thing.

So we have to use a local "bound copy" of our list item behind our power app edit screen, refresh the etag knowledge to current,  by refreshing the data source, then we submit the changes on the edit form to Sharepoint. It sounds difficult but it is quite easy.

In my case I am moving from a gallery button push to an edit form for a standard submit. So, I have to bind my form hard to the gallery item button push,  by navigating to the second form with the selected item in the optional parm of the navigate command. Nanoseconds before we submit our list item changes on the edited form, we must refresh the list data source, and submit with the form data mods. The issue I had, was the edit form was bound to the gallery selected item, and refreshing the source wiped the field edits I was typing in! (very disheartening to see the edits revert!)  Navigation with the bind option, you are updating a copy of the record that is submitted from what is essentially like a global variable cache. The refresh DOES wipe the visual data on the form at the instant of submission, which looks really wierd, but the submit works, and when the submit form closes on submit, and navigates back to the gallery, all the desired mods are there staring you in the face. Kudos to Microsoft on this little hack, particularly Resa who has guided us here, and a gent named Alan who's handle I do not know. I am including the two "magical" code snippets that saved my gluteous maximus in the meeting I have in 20 hours with a director to explain why this does not works! 

Nav to your edit form that is getting the ETAG error with this code from the gallery button selector to the edit form:

Navigate(MyEditScreen2, ScreenTransition.None, {SelectedItem: MyBrowseGallery1.Selected})

notice that third optional parm is the list item to gallery super glue.

Put this code in the submit on that form that gets the errors (check box upper right) of the submit form:

Refresh(MySharePointListName);SubmitForm(MyEditForm2)

The fundamental technique is to modify your data record on a form object, not tightly bound to the list item. In this case I believe the gallery "selected" table row variable is being modified on the form now, but the data is submitted to the backend list just as it would be if it were tightly bound to only the list item object. 

I hope this helps folks out, sorry if it is too wordy. I was in a bit of a quandry with this particular app, since it was very difficult to see hope when all you get is an evil red error. Flow is acting as a concurrent update, and multi user scenarios will hammer you the same way.  ( If you are wondering, the way you see all these amazing things happen is by using Chrome and hitting CTRL+SHIFT+i  These keys open a debugger window. Go to the network tab and you can filter down to all the behind the scenes traffic that the browser is spewing with your form submission.) 

[skylitedave]

Are you saying that the fix is to add a refresh of the list before you submit the form?

Thx