Web request fails in production but not in test/dev

Hi,
We have a service that retrieves data from our database. If I test this service in the devtools in both test and production everything works fine, but whenever I test this in production it throws this error:

As you can see in the picture it as write conflict that uccurs in a persist data action. I don’t understand why it happens in prod but not in any other environment. Is there a way to debug this further?

I saw another post that was similar but no solution was.
Any help is appreciated.
Thanks!

Hi Robin

Seems for me like your web request is working , it looks more of a persist object problem.
do you think it is linked to your web request ? or maybe i’m not understanding the problem correctly

also , does your persist is launched in previous iterations ? here i can see that you are already on iteration number 20

peace :smiley:

Yes exactly! It works all the way to iteration nr 20, then the persist action fails. The web request seems to be working fine, so I think the issue is the persist.

This is how it looks:

Its not the full service but it is enough to see where the problem can be. It happens in the persist context data in Response.

I ran the service again in the devtools and it seems to throw the error at different iteration.

Does it always fail on iteration 20, or is it random when it fails? And are there exactly 20 iterations, meaning it always fails on the last?

This looks like an issue related to concurrent write operations, so if you have any parallel execution stuff going on that would probably be the place to start looking.

I edited the post above just when I saw you responded. It does not happen exactly at iteration 20 all the time as stated above.

Looks like this is inside a foreach that iterates some Responses, right? Is it set to parallel or sequential execution?

It shouldn’t really matter though, since each iteration would have a different object in context :thinking:

Maybe your service gets called twice? Can you try to turn on No Concurrency on the endpoint and see if the problem persists?

image

3 Likes

Checking the No concurrency solved the problem. Thank you so much for all the help!

No problem, although I would suggest hunting down the source for why your service got called twice too so you don’t get any nasty client errors :smiley: