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.

[Anonymous]

With all due respect, but no, this is not the next logical advancement in the open source movement.  It is simply poor quality control.  

[Panoone]

I realise this thread is two years old but we have just experienced a reoccurrence of this error today...in 2020.

Same scenario to reproduce.

Has this problem somehow been re-introduced?

Was it ever recognised as an issue?

Is there a viable fix for our SharePoint list-connected apps?

[bosscon1]

So, I'll tell you from my perspective, this ONE issue caused me to close shop with powerapps and find another avenue for our programming needs.  It's a shame, because Powerapps shows promise from time to time, but the ETAG mismatch BUG was never properly addressed that I ever saw with anything other than a temporary workaround.  This bug shut down the three apps we had in development, because it made all of our apps unstable and unreliable.  I tried all of the suggested solutions, to the point of rebuilding apps from scratch with all of the suggested coding workarounds included.  It's a shame to hear that even though a year has passed since we moved away from this platform, the problem still persists!

[Reza]

Hi all,

Sorry to hear that you have problem with your ETags. Couple of questions to help us track the issue. 1- Do you have a Flow or other processes that changes SharePoint list automatically? 2- Do you use attachments in your list?

Thanks

[SmartMeter]

Thanks @Reza , This was an associated flow trying to concurrently update while the SP list object was being edited in an app gallery. Fixed it by removing the need for the flow, and the problem went away.

[Panoone]

Hi @Reza ,

There is no Flow and attachments are disabled.

The form has been working fine for 5 months.

I haven't attempted to reproduce the problem as yet because the list is in use and in production.

[SmartMeter]

Thoughts:

1) Are multiple users updating the same list item with the app?

2) Are you patching the records or using the form submit method? In theory you can do this by patching something that is not current and in sync with the backend.

3) If it's been in prod (working) for a time, have you added any new users or changed the backend (new paradigm)

4) I only resolved the ETAG error after I tested to find the repeatable conditions that made it happen. This helped me zero down on the actual issue (flow update colliding with app submit, or patch. Neither method would work consistently!)

Good luck testing!

[Panoone]

1. Do you mean concurrently? Unlikely but always possible. I still wouldn't expect an ETAG mismatch from this.
2. Straight-up SubmitForm method, no patching, no refreshes. There is no gallery. This is an out-of-the-box list-connected app.
3. There are always users coming and going. Not sure of relevance. Not sure what you mean by "changed the backend". The data source and list fields have not changed.
4. I'm waiting to see if it recurs or if it was a temporary glitch.