You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Register over reelle rettighetshavere dokumenterer hvem som har fylt ut / signert / sendt inn et skjema ved å hente processHistory for instansen og lagre det i et saksgrunnlag på vår side.
Dette gjør vi rett etter at vi har hentet ned instanser med status "complete" fra Storage API'et.
I produksjon har vi observert at vi ved flere anledninger henter processHistory som ikke inneholder komplett informasjon. Vi mangler feks det siste prosessteget "BREnd" som er det viktigste steget da det indikerer hvem som har signert/sendt inn skjemaet.
Dette skjer mest sannsynlig pga en "race condition" i Altinn der oppdatering av processHistory / instance events(?) har lavere prioritet, og ikke er oppdatert selv om selve skjemaet har status "complete".
Hadde en dialog med Alexandra Vedeler som igjen sjekket litt med core teamet, og hun/de beskrev følgende:
De instansene man får tilbake med flagget isComplete skal alle være avsluttet (Instance.Process.Ended), men:
"Logging til InstanceEvents skjer normalt synkront mot databasen i sammenheng med andre operasjoner, men InstanceEvents er ikke viktige nok til å kunne hindre andre operasjoner om det mot formodning skulle skje en feil. Derfor er det mulig å ha Instances med små hull i historikken."
Hvis processHistory skal ha noen form for verdi må vi være sikre på at når et skjema har utført det siste prosessteget, og har status "complete" må vi kunne være sikre på at også processHistory er oppdatert.
Det kan evt løses ved at instanser ikke skal ha status "complete" før også processHistory er endelig oppdatert.
Men samtidig må vi ikke risikere at instanser aldri blir "complete" pga et eller annet problem med å få oppdatert processHistory.
Additional Information
No response
The text was updated successfully, but these errors were encountered:
Description
Observert i tilknytning til følgende app (men det samme gjelder sannsynligvis for alle apper):
brg/rrh-innrapportering
Endepunkt som brukes for å hente processHistory (eksempel fra TT02):
https://brg.apps.tt02.altinn.no/brg/rrh-innrapportering/instances/50121548/f2209120-b6e3-4160-9b6d-aec4c7a9d16a/process/history
Beskrivelse:
Register over reelle rettighetshavere dokumenterer hvem som har fylt ut / signert / sendt inn et skjema ved å hente processHistory for instansen og lagre det i et saksgrunnlag på vår side.
Dette gjør vi rett etter at vi har hentet ned instanser med status "complete" fra Storage API'et.
I produksjon har vi observert at vi ved flere anledninger henter processHistory som ikke inneholder komplett informasjon. Vi mangler feks det siste prosessteget "BREnd" som er det viktigste steget da det indikerer hvem som har signert/sendt inn skjemaet.
Dette skjer mest sannsynlig pga en "race condition" i Altinn der oppdatering av processHistory / instance events(?) har lavere prioritet, og ikke er oppdatert selv om selve skjemaet har status "complete".
Hadde en dialog med Alexandra Vedeler som igjen sjekket litt med core teamet, og hun/de beskrev følgende:
De instansene man får tilbake med flagget isComplete skal alle være avsluttet (Instance.Process.Ended), men:
"Logging til InstanceEvents skjer normalt synkront mot databasen i sammenheng med andre operasjoner, men InstanceEvents er ikke viktige nok til å kunne hindre andre operasjoner om det mot formodning skulle skje en feil. Derfor er det mulig å ha Instances med små hull i historikken."
Hvis processHistory skal ha noen form for verdi må vi være sikre på at når et skjema har utført det siste prosessteget, og har status "complete" må vi kunne være sikre på at også processHistory er oppdatert.
Det kan evt løses ved at instanser ikke skal ha status "complete" før også processHistory er endelig oppdatert.
Men samtidig må vi ikke risikere at instanser aldri blir "complete" pga et eller annet problem med å få oppdatert processHistory.
Additional Information
No response
The text was updated successfully, but these errors were encountered: