-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OTR(Backend & Frontend) OPHOTRKEH-248: NPE/Enum korjaus kun ONR-tiedot muuttuneet #587
Conversation
Toi ongelma vaikuttaa olevan oire toisesta - jostakin syystä API-kutsu ONR:ään ei toimi:
Toinen huomio, että en lähtisi korjaamaan dataongelmaa koodilla. Oikein toimivassa ympäristössä kääntäjän/tulkin oidNumero viittaa olemassa olevaan henkilöön ONR:ssä. Nyt tolla fixillä piilotetaan kääntäjiä/tulkkeja kokonaan pois käyttöliittymästä. Itse korjaisin tuon siten, että lisäisin ylimääräisen lokituksen oidNumerosta ja sen perusteella korjaisin dataa Untuvalla/Pallerolla. Tuotannossa tota tilannetta ei pitäisi syntyä, koska tietokantaan lisätään olemassa olevat henkilöt ONR:sta. |
Ajattelin tässä, että olisi kuitenkin parempi näyttää ne tulkit, joiden tiedot löytyy, kuin että ei näytetä mitään. Joka tapauksessa NPE pitäisi varmaankin ottaa kiinni ja vaikka palauttaa jokin hallittu virhe APIsta. 🤔
Onkohan mahdollista, että tulkki poistuu ONR:stä mutta pysyy edelleen OTR:ssä? En ole kovin tarkkaan katsonut niin en tiedä onko siellä jotain poistorutiinia. 🤔 |
Tuossa on se vaara, että toi fixi piilottaa alkuperäisen ongelman, joka johti tähän tilanteeseen ja jota pitää korjata ensi sijassa. Toimintalogiikan ei kai pidä varautua kaikkiin teoreettisiin tilanteisiin, jos niihin ei voi päätyä ohjelmaa oikein käytettynä.
Joo, toi varmaan vois tehdä.
Veikkaisin, ettei ONR poista muista järjestelmistä mitään. Toisaalta epäilen suuresti, että ONR poistaisi omatoimisesti henkilöä, vaikka teoriassa se on kai mahdollista... |
...ja jos päätetään sisällyttää tämä null check, se pitää myös korjata ainakin kahteen muuhun luokkaan: ClerkInterpreterService ja ClerkEmailService (jos searchaa IDE:ssä onrService.getCachedPersonalDatas). Eli sanoisin, että toi on vahvasti dataongelma, ja se kannattaa korjatakin datan puolella. |
…ix unknown enum in contact source
import com.fasterxml.jackson.annotation.JsonProperty; | ||
|
||
@JsonIgnoreProperties(ignoreUnknown = true) | ||
public enum ContactDetailsGroupSource { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pitäisikö se lisätä myös ContactDetailsGroupType? Siihen voi myös tulla uusia tyyppejä.
…ronized between OTR and ONR [deploy]
@Transactional(readOnly = true) | ||
public List<ClerkInterpreterDTO> list() { | ||
final List<ClerkInterpreterDTO> result = listWithoutAudit(); | ||
auditService.logOperation(OtrOperation.LIST_INTERPRETERS); | ||
return result; | ||
} | ||
|
||
@Transactional(readOnly = true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@transactional ymmärtääkseni vaikuttaa vain tietokantakutsuihin, tuossa sillä ei ole väliä, koska tietokantaa ei kutsuta.
…t muuttuneet (#587) * OTR(Backend) OPHOTRKEH-248: NPE fix when interpreter is not found from cache * OTR(Backend) OPHOTRKEH-248: NPE fix when not found from cache. Also fix unknown enum in contact source * OTR(Backend) OPHOTRKEH-248: test for ONR response deserialization * OTR(Backend) OPHOTRKEH-248: test for ONR response deserialization * OTR(Frontend) OPHOTRKEH-248: show alert if interpreters are not synchronized between OTR and ONR [deploy] * OTR(Frontend) OPHOTRKEH-248: mock-up endpoint for missing interpreters [deploy] * OTR(Frontend) OPHOTRKEH-248: error handler for missing interpreters [deploy]
Yhteenveto
Estetään NPE ja logitetaan virhe kun tulkin tietoja ei löydy cachesta. Toistuu untuvalla. Oletettavasti koska AKR ylikirjoittanut tiedot.