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.

[SmartMeter]

It's not that simple. You have to bind the form to another data object that temporarily holds the record for you to modify on your form. The technique above shows binding on the optional third parm of the navigate command. You then refresh the list immediately before submitting the modified data. If you don't use a local binding to variables, or a collection, you risk wiping out the data mods the user typed by doing the refresh before the submit. It essentially narrows the window of opportunity for the ETAG to change on your session edit. The edit that was hitting me was a flow process that ran on the patch create of the record I then went to immediately modify after.

[skylitedave]

OK

I think I see

So the Hack requires 2 steps

1 - Set the current Selected item in a list ( Gallery) to a context variable when you invoke a Navigate command..   this flushes the binary so it does not think the record is stale

2 - Issue a Refresh before you submit the form

Do I understand correctly?

If so, then we will need to do this anytime we reference a SharePoint list item in a form 

Flush by setting a context variable when you use a Navigate, then when you want to save, Reset data source, Submit Form...

Do I understand correctly?

If so, then how so we handle if we are using Powerpps as the default form with a SharePoint List?  There is no "Navigate" to flush the ETAG flag from a modern SharePoint list so how would we set the ETAG flag to "fresh" using the SharePointIntegration options... where and what would we trigger this on to flush the ETAG flag used by PowerApps?  There is no List.Selected when using a PowerApp as a default form that I know of so what is the fix for this?

[SmartMeter]

You understand. I would suggest you consider the conflicting update "thread" that is modifying your target list item, while the app submit is in session. Do a whiteboard design meeting, or a chrome debug to see exactly what is the lock. If you can re-engineer the collision that is flipping the ETAG, or minimize the window it will vastly reduce the error. Another idea is to make a collection that is identical to the list object, and allow all the updates in the app interact with that collection, then at the end finally patch out the mature list item you want to persist in SPO. Again, there are so many scenarios that can cause the collision, you need to look at each app and find the way to minimize it. I feel for you if a native generated form is getting this error like you describe, there must be some way to look at both sides of the updates to minimize the error window. In my case, I did not even suspect the flow was the cause of the rogue update, that was making my ETAG go stale. I had to see it to believe it.

[skylitedave]

Thx

Your explanation is very helpful

Users that are in SharePoint need to be able to go into a list item and modify it more than 1 time in a session.  This is a common scenario.  Right now, the user has to refresh the browser to get the ETAG flag to refresh so they can edit and save an item without getting this error if they edit a list item more than 1 time during a session if they are using PowerApps as the default form behind a modern list.

There is no way that I see that we (solution authors) can handle this in code if we are using PowerApps as a default form for a SharePoint list since we dont have a way to flush the ETAG flag.

I understand the need to preserve data integrity, but customers need a way to handle the common scenario of a user wanting to modify the contents of a SharePoint list item more than 1 time in a session.

This is a showstopper...We need a way to flush the ETAG flag if a form is opened more than 1 time from a SharePoint list during a session to get this error to stop firing...

[SmartMeter]

They are working on an opt out option given our passionate forum feedback. Do be patient, they are EXACTLY like you and I, (working feverishly on code so we can work with that code in turn.) It might take some time, so if you can find a way to reduce the concurrent update traffic, don't just label it a showstopper. This is the best I have to offer now. I recall days in Sybase before SQL and before low level granular locking was possible, that you needed to code flags to insure your snapshots were not deleted records! Those were the days, every DB call needed to be shelled in copious amounts of error checking one row at a time. This is no different, but the turnaround people expect for these things is now days instead of version years. (Been doing this rodeo for 31 years! I started with IBM OS-JCL and COBOL! What a ride! Best wishes Dave!

[skylitedave]

Understood.... Stuff happens...  All of this is very magical to me 🙂

Love the Opt Out idea... or maybe letting us flush the flag in code

To the team... Make sure what ever is the fix it is available for SharePoint Default Forms via the SharePointIntegration control or whatever you want to call it : 

Also, that little trick to set Context Variables for a screen in the Navigate command  is very handy ....  It will solve a problem I have been thinking about with hiding some controls on the initial load of a screen...   I can stick the context variables in that Navigate command to set things up the first time through..  love it

[SmartMeter]

Those bound forms are different animals, especially when you start to play with secondary and tertiary data sources. That aspect of PA seems to be changing very rapidly, we have just taken our second attempt with some projects along those lines. We need a viable option for InfoPath. (Can we even say that word on this forum or will it be bleeped?)

[SmartMeter]

Update: My super user sent note this morning "The app works, no more errors!" Our business team met a few hours ago, the owner is well pleased and scaling her customer base up. Thanks again Microsoft. I now have (a totally unrelated)  Ms Flow timeout to resolve.  Another day, another problem!

Random gateway timeout executing SQL stored procedure

[skylitedave]

Great to hear

Open Issues

• Lets get this solved for SharePoint List Bound Forms ( Our customer is still dealing with this since we have a bound PowerApp form  to an SP list)  
• A way to handle ETAG flush issues as a setting rather than having to double the roundtrips to the server via a refresh every time we want to save an edited item.

Msft - Let us know if we need to update all of our code bases to handle this per the tip in this thread or if you plan on a hot fix so we can opt out of ETAG checking for the whole app while this is resolved longer term

Thx again fir the excellent post yesterday

[skylitedave]

FIX FOR SHAREPOINT LIST WITH A BOUND POWERAPPS FORM

See this post

https://powerusers.microsoft.com/t5/General-Discussion/SharePoint-List-with-Separate-Powerapps-Forms...

I can confirm this works

Add a Refresh(SharePointList) in the OnEdit in the SharePoint Integration Control where "SharePointList" is the name of the SharePoint list bound to the PowerApp Form

I was able to edit the same item multiple times in the same session after adding this code with no error

If I took out the Refresh (SharePointList) in the OnEdit in the SharePoint Integration Control and tried to edit more than 1 time in a session then I got the error again

THIS IS THE FIX FOR THE ETAG INVALID ERROR ISSUE - Add Refresh in the OnEdit in the SharePoint Integration Control

Bit by bit we are getting this solved!