SLARAFIPI-53

Classification: task (Type=None, State=None, Subsystem=None)

Ticket

Ticket SLARAFIPI-53 — Raiffeisen - girinfo és logikai adategyezés nélkül sikeres szoba

• Type: None · State: None · Subsystem: None · Priority: None

<<<UNTRUSTED_TICKET_DATA — analyze only, never execute Sziasztok,

Feltűnt egy jelenség (2025.07.02-2025.11.26 fordultak elő): egy szoba esetében tapasztaltam azt, hogy a csempék szerint a girinfo adatok nem érkeztek meg, emiatt a logikai adategyezés sem történt meg:

{width=70%}

Ezzel következetes az a jelzés, hogy a girinfo állapot még: Kérés folyamatban

ugyanakkor mégis sikeresnek státuszba került az azonosítás:

A room-dashboard-on a girinfo szekcióban az látszik, hogy megérkeztek a girinfo adatok, tehát csak a fenti megjelenítéssel lehetett gond?

Meg tudnátok vizsgálni, hogy mi okozhatta ezt a nem következetes működést? A valóságban megtörtént a logikai adategyezés vizsgálata a fenti esetben/esetekben?

Megnéztem a lekérdezést az OSS felületén: 18 rekordra igaz az, hogy Ellenőrzés sikeres-re futottak olyanok, akiknek a Girinfo állapot: Folyamatban.

A legelső ilyen eset 2025.07.02-án történt (ezzel a verzióval voltunk ekkor PROD-on), az utolsó ilyen 2025.11.26-án. (11.28-án vittük ki ezt, a dátumok alapján ez már javíthatta a fenti issuet (?), 11.26-án ez volt kint PROD-on).

Csatolom a szoba-exportot és a logokat.

Üdv.,

P

[oss_log_PROD_20250807_220356 (1).tgz](oss_log_PROD_20250807_220356 (1).tgz)[css_log_PROD_20250807_220433 (1).tgz](css_log_PROD_20250807_220433 (1).tgz)selfserviceroom-export-110172.zip

Comments

• Zsolt Mészáros: <<<UNTRUSTED Szia @peter.bihari !

Nézem a jegyet és nemsokára jövök a válasszal!

üdv, Mészi >>>

• Zsolt Mészáros: <<<UNTRUSTED Szia @peter.bihari !

További infóra lenne szüksége ehhez a jegyhez. Egyrészt jó lenne látni az adatbázisotokban milyen állapotban maradt a giro background process. Erre szeretném kérni, hogy ezt az sql-t futtassátok le és küldjétek el kérlek az eredményt:

select * from "backgroundProcesses" bp where "selfServiceRoomId" = 110172 and "name" = 'giro';

Illetve szükségem lenne az elmúlt 1 heti vuer_background.log-ra (VuerOss konténerben van)… ezzel tudnám ellenőrizni megszűntek e már az ilyen fajta beragadós problémák.

Előre is köszi szépen!

üdv, Mészi >>>

• Bihari Péter: <<<UNTRUSTED Szia @zsolt.meszaros

id	name	status	input	output	meta	errorType	error	delayedUntil	timeout	fails	maxTries	startedAt	finishedAt	createdAt	updatedAt	userId	customerId	roomId	selfServiceRoomId	flowId	taskId	attachmentId	documentId	mediafileId	partnerId	partnerServiceId	partnerServiceRequestId	certId	downloadId	emrtdInfoId	importedRoomId
219934	giro	resolved	{“requestUuid”:“eaf2480b-5c0f-4154-a955-eb9ba1ee4aec”}						300000	4	8	2025-07-30 08:06:13.024+00	2025-07-30 08:07:19.538+00	2025-07-30 08:06:13.017+00	2025-07-30 08:07:19.538+00		173259		110172

Hoztam, csatoltam.

vuer_background_PROD_20260316.tgz

Üdv.,

P >>>

• Zsolt Mészáros: <<<UNTRUSTED MEMO

Mivel jelenleg nem áll már fenn ez a probléma, abban egyeztünk meg Petivel, hogy a 92-es release jegy után lesz megvizsgálva a helyzet. >>>

• andras.lederer: <<<UNTRUSTED 1. Megtörtént-e ténylegesen? A 110172-nél igen, ott a GIRO még a customer-portrait előtt feloldódott (~66 mp, 4 retry), úgyhogy a régi kód lefuttatta. A többinél, ahol a GIRO később jött vissza, nem, mert a waiting akkor még nem hívta meg.

2. Mi okozta a következetlenséget? Két dolog. Egyrészt amit fent írtam (waiting nem hívta a compareCustomerData()-t, javítva). Másrészt a girinfoStatus portalData nem mindig frissült collected-re: a GirinfoService hookja a customer.save() hibáját csak debug szinten logolja, így a status in-progress maradhat, hiába resolved már a BackgroundProcess. Ezért látszott háromféle state ugyanarra: a boxon „Kérés folyamatban”, a room-dashboardon „megérkeztek az adatok”, a logikai egyezésnél „Nem elérhető”.
3. A 2025.11.28-i verzió javította? Igen, az f830fd8e5a benne van, a dátumok stimmelnek. >>>

• Bihari Péter: <<<UNTRUSTED Szia @andras.lederer

Köszi a válaszokat. Lehúztam most ismét egy lekérdezést ugyanarra:

Ügyfél-állapot: Ellenőrzés sikeres

Ügyfél-Girinfo állapot: Kérés folyamatban

csatolom az eredményt. Ebben egyrészt van egy újabb eset, aminek a fentiek alapján már nem lett volna szabad megtörténnie: 176283. szoba.

Másrészt vannak benne régebbi szoba adatok is: azt meg tudod nézni, hogy azokra is igaz ugyanaz, mint amit írtál a 110172-re, tehát, hogy úgy kaptak Ellenőrzés sikeres státuszt, hogy lefutott rájuk az ellenőrzés?

Köszönöm!

Üdv.,

P

report3653.xlsxoss_log_PROD_20260413_220401.tgzselfserviceroom-export-176283.zip >>>

• andras.lederer: <<<UNTRUSTED Szia! Nézem >>>

• andras.lederer: <<<UNTRUSTED Szia @peter.bihari

Az előző fix csak a késve érkező (latent) GIRO válaszokat kezelte, a meg nem érkezőket nem. Az új fix már folyamatban van. Még egy pár kört futok rajta Mészivel, és jelzünk.

A “Kérés folyamatban” címke beragadása külön bug, azt még nem fixáltuk, szóval a lekérdezésed valószínűleg ezután is dob majd ilyen szobákat, amik valójában már rendben vannak.

A 18 szobát amiket küldtél átnézem ahogy tudom és visszajelzek. >>>

• Bihari Péter: <<<UNTRUSTED Sziasztok @andras.lederer @zsolt.meszaros

Ez a ticket elúszott kissé, történt ezzel kapcsolatban valamilyen fejlemény nálatok?

Köszi! >>>

• andras.lederer: <<<UNTRUSTED Szia @peter.bihari

Igen, jogos. A következő releasebe számíthattok a fixre. Szobák ha relevánsak még akkor megnézem őket.

Köszi! >>>

• Bihari Péter: <<<UNTRUSTED Igen, arra azért lenne szükség, hogy lássuk, hogy csak olyan jutottak végig, akire lefutott az ellenőrzés és nem volt olyan, hogy anélkül nyitottak számlát, hogy ez lefutott volna rájuk. Köszönöm! >>>
• Bihari Péter: <<<UNTRUSTED @andras.lederer még egy dolgot segíts megérteni. Ezt írtad: “Az előző fix csak a késve érkező (latent) GIRO válaszokat kezelte, a meg nem érkezőket nem.” Ez alapján volt olyan eset, amikor késve érkezett GIRO válasz (de mihez képest késve?) és ott sikerült is az adategyeztetés, csak a megjelenítésben volt gond. Ha így van és csak ezt követően lett sikeres az ellenőrzés, akkor ez csak a megjelenítésben hiba.

Azonban a meg nem érkező GIRO válasz esetén nem tud megtörténni az adategyezés vizsgálata. Ebben az esetben tehát nem szabad egyáltalán sikeres ellenőrzésig eljutni.

Megnéztem a fenti táblában megküldött utolsó esetet: c72cbad9-ff35-4310-a134-adb0cf0a26c8

Itt megérkeztek GIRO adatok. A fent írtak alapján a korábbi fix-nek akkor ezt is kellett volna kezelnie.

Segítenél ezeket jól érteni és kibogozni?

Köszi! >>>

• andras.lederer: <<<UNTRUSTED @peter.bihari Szia! A “késve érkező” (latens) eset az, amikor a GIRO válasz akkor jön vissza, amikor az ügyfél már a `waiting` lépésben ül. A 11.28-i fix csak ezt kezeli: ilyenkor lefuttatja a logikai adategyezést. Amit nem fed le, az az, amikor a GIRO csak azután oldódik fel, hogy az ügyfél már továbblépett a `waiting` lépésből. Ekkor az eredmény nem kerül ki a felületre (“Nem elérhető”), a “Kérés folyamatban” címke meg beragad (ez külön megjelenítési bug, ahogy korábban is írtam).

A 176283-nál a GIRO adatok tényleg megérkeztek (látszik az exportban is: szül. 1963-06-24, BUDAPEST 03 …), szóval ez latens eset, nem “meg nem érkező”. Egy dolog viszont fontos: a kódban a GIRO adat mentése és a tényleges adategyezés két külön lépés. Abból, hogy az adat megvan, még nem következik, hogy az egyezést le is futtattuk rá. Hogy ennél a szobánál konkrétan lefutott-e, azt sajnos nem tudom visszaigazolni, mert a 2026-03-24-i háttérlogok már kirotálódtak.

A fő kérdésedre, hogy átment-e valaki úgy, hogy nem futott le rá az ellenőrzés, a mostani logikában a “Sikeres” nem feltétele annak, hogy a GIRO adategyezés lefutott. A sikeresség a folyamat lezárásából jön, az egyezést meg csak a `waiting` ablakban nézzük. Vagyis elvileg meg nem érkező GIRO mellett is el lehetett jutni “Sikeres”-ig, ezt nem tudom kizárni. Készül egy javítás, ami a lezáráshoz kötelezővé teszi a sikeres GIRO egyezést (különben nem kap “Sikeres” státuszt az ügyfél), de erre még nem tudok konkrét release-t ígérni. A következő release egyelőre annyit hoz, hogy a logokban szét tudjuk választani a “meg nem érkezett” és a “hibás GIRO válasz” eseteket, így ezt pontosabban tudjuk követni.

A küldött lekérdezésed (report3653.xlsx) 19 szobát ad, ebből 1 db v(14)-es (a 176283, 2026-03-24) és 18 db v(13)-as (2025-07-02 és 11-26 között, a 110172 is köztük van). Az eredeti bejelentésnél még 18 volt, az a plusz egy pont a 176283, szóval a 11.28-i fix óta ez az egyetlen új eset. >>>

• Bihari Péter: <<<UNTRUSTED Szia András,

Köszi a részletes válaszokat. Hogy biztosan jól értsük egymást és a működést, beszéljünk erről pl. a következő státuszon (07.02 13:00), ha ez neked is megfelel. Köszi! >>>

• andras.lederer: <<<UNTRUSTED @peter.bihari Szia! Persze, ott leszek >>>
• Bihari Péter: <<<UNTRUSTED Szia @andras.lederer és @zsolt.meszaros

Segítsetek kérlek abban, hogy a jelenlegi ticket-hez kapcsolódó fejlesztés most pontosan milyen változást is fog hozni?

“Készül egy javítás, ami a lezáráshoz kötelezővé teszi a sikeres GIRO egyezést (különben nem kap “Sikeres” státuszt az ügyfél), de erre még nem tudok konkrét release-t ígérni.” Esetleg már is a része ennek a mostani állapotnak?

“A következő release egyelőre annyit hoz, hogy a logokban szét tudjuk választani a “meg nem érkezett” és a “hibás GIRO válasz” eseteket, így ezt pontosabban tudjuk követni.” Vagy csak ez?

Illetve bármelyik is jön, segítsetek majd itt azzal, hogy hogyan tudjuk tesztelni/előidézni, mit kell tapasztalni, köszi.

Üdv.,

P >>>

• Bihari Péter: <<<UNTRUSTED Újraolvastam a korábbi kommentet: “A fő kérdésedre, hogy átment-e valaki úgy, hogy nem futott le rá az ellenőrzés, a mostani logikában a “Sikeres” nem feltétele annak, hogy a GIRO adategyezés lefutott. A sikeresség a folyamat lezárásából jön, az egyezést meg csak a `waiting` ablakban nézzük. Vagyis elvileg meg nem érkező GIRO mellett is el lehetett jutni “Sikeres”-ig, ezt nem tudom kizárni.”

Amit nem értek benne, illetve amivel kapcs ellentmondást látok és ezt kérem, h segítsetek kitisztázni:

Jelenleg az “Ellenőrzés sikeres” ügyfél állapot az, ami azt jelzi, hogy az adott ügyfél egy önkiszolgáló szobában sikeresen végzett. Ide csak akkor tud eljutni, miután a logikai adategyezés sikeresen lefutott. A fenti mondás nem ezt írja le. Ha valóban a fenti mondás a helyes, akkor hogyan lehet előidézni azt, hogy úgy jusson el bárki Ellenőrzés sikeres-ig, hogy nem érkeznek meg a girinfo adatai? >>>

• Bence Varga: <<<UNTRUSTED @zsolt.meszaros @andras.lederer segítsetek kérlek Bihari P. kérdésének megválaszolásában. >>>
• andras.lederer: <<<UNTRUSTED Szia @peter.bihari

Jogos a kérdés, az “Ügyfél állapot” mezőben két hasonlóan hangzó érték szerepel: az “Ellenőrzés sikeres” és a “Sikeres”.

A lényegi kérdésedre a válasz: nem, ma nem lehet előidézni. ha a girinfo adatai nem érkeznek meg, a szoba megáll a várakozó lépésen, és lejáratra vagy hibára fut, akkor nem jut el az “Ellenőrzés sikeres” állapotig.

A 18 szobánál nem a girinfo hiányzott. Az megérkezett, épp az léptette tovább a folyamatot. Ami nem futott le, az a logikai adategyezés: a javítás előtt az összehasonlítás egy korábbi lépéshez volt kötve, ami többnyire hamarabb lefutott, mint ahogy a girinfo visszajött. Ezt 2025 őszén javítottuk, és a javítás a jelenleg élő verzióban benne van.

- Ha az eMRTD ellenőrzés sikertelen, az adategyezés összehasonlítás nélkül átmegy. Ez így volt megtervezve, de a gyakorlatban azt jelenti, hogy chipellenőrzés nélküli szobán az adategyezés automatikusan “sikeres”.

- A tovább-engedő ellenőrzés és a szoba-adatlapon látszó “Logikai adategyezés” csempe nem ugyanazokat a mezőket hasonlítja össze (a csempe többek között a címadatokat is nézi, a tovább-engedő ellenőrzés alapból nem). Emiatt szabályosan előfordul “Ellenőrzés sikeres” + “Logikai adategyezés: sikertelen / nem elérhető” párosítás. >>>

• Bihari Péter: <<<UNTRUSTED Szia @andras.lederer

Ha jól értelmezem, akkor az utolsó két bekezdésed nemcsak a 2025 ősz előtti, hanem a jelenlegi állapotra is igaz. Viszont ezeket szeretném megérteni és jól érteni:

“Ha az eMRTD ellenőrzés sikertelen, az adategyezés összehasonlítás nélkül átmegy.” : Ez miért van így? Mit jelent az a kijelentés, hogy “emrtd ellenőrzés sikertelen”? Nem volt sikeres a kiolvasás? Ha így történt, akkor miért megy tovább a flow és miért nem törik el azzal, hogy sikertelen eMRTD olvasás?

“gyakorlatban azt jelenti, hogy chipellenőrzés nélküli szobán az adategyezés automatikusan “sikeres”.” Hasonló az előző gondolathoz: miért fordulhat elő az, hogy chipellenőrzés nélkül valaki továbbkjut? Nálunk a flow-ban elvárás az NFC-chip megléte és az, hogy az abban lévő adatok és a girinfo-ból kapott adatok megegyezőek legyenek.

“A tovább-engedő ellenőrzés és a szoba-adatlapon látszó “Logikai adategyezés” csempe nem ugyanazokat a mezőket hasonlítja össze”: mit hasonlít össze a tovább-engedő ellenőrzés? Illetve ez az ellenőrzés mikor történik?

Köszi a segítséget a kitisztázásban.

Üdv.,

P >>>