Samtidige skriveoperasjoner uten If-Match header gir 412 Precondition Failed

[elsand]

Beskrivelse

Samtidige skriveoperasjoner uten If-Match header gir 412 Precondition Failed

Reproduksjon

Kjør mer to eller flere paralelle POSTs til en barneentitet, f.eks. activities.

Se #348 for e2e-test som viser dette

Forventet oppførsel

Alle gyldige og samtidige POST requests for å legge til en barneentitet, eller PUT for å oppdater en (barne)entitet uten If-Match request header skal returnere 2xx Rekkefølge er ikke definert, "last request wins".

Faktisk oppførsel

Det returneres 412 Precondition Failed

Ytterligere informasjon

For POST på barneentiteter blir det uansett foretatt en full update på hele aggregatet hvor optimistic concurrency control uansett blir foretatt, selv om sluttbruker ikke oppgir If-Match-header. I de tilfellene må vi på en eller annen måte deaktivere denne kontrollen, eller gjenta forsøk inntil skrivingen lykkes.

Concurrent writes uten å oppgi If-Match er forøvrig noe vi ikke tilbyr noen garantier rundt mht konsistens på rekkefølge, men hvis tjenesteeier implisitt oppgir at han ikke bryr seg om f.eks. rekkefølgen på dialogelementer som legges til samtidig, skal dette kunne støttes (og innebære individuelle events).

Det er pt ikke mulig å dynamisk opte-ut av optimistic concurrency-håndteringen i EF, dette blir muligens støttet som følge av dotnet/efcore#10443. Løsningen må derfor inntil videre være at vi i disse tilfellene forsøker på nytt (og på nytt) inntil vi faktisk klarer å gjøre oppdateringen.

EF kaster her en exception knyttet til concurrency-sjekken feiler. Fra denne vil det være mulig å hente ut revision-ID-en som faktisk ligger i databasen, og forsøke på nytt. Se https://learn.microsoft.com/en-us/ef/core/saving/concurrency?tabs=data-annotations#resolving-concurrency-conflicts

Tasks

Preview Give feedback

1. Legg til removeFromSchema på alle "Revision"-properties som egentlig er tiltenkt bindet fra If-Match-headers, og rename til "IfMatchDialogRevision" elns
2. Implementere retry ved DbUpdateConcurrencyException ved bruk av en jitter Polly-policy (sleep i 1-10ms). Gi opp etter 10 sekund, og la det bli kastet 500 internal server error

Se også

• Allow opt-out of optimistic concurrency/rows affected check in the model dotnet/efcore#10443
• https://learn.microsoft.com/en-us/ef/core/saving/concurrency?tabs=data-annotations#resolving-concurrency-conflicts

[MagnusSandgren]

Gjelder alle oppdateringer på dialog aggregatet, ikke bare underentiteter