Levandor

Raiffeisen 1.9.11.100 — TjK section drafts (ASSRAFIPI-119, SLARAFIPI-60)

10 min read

Finished Hungarian TjK section drafts for two tickets of the Raiffeisen 1.9.11.100 release — ASSRAFIPI-119 (FKITDEV-8827, face-comparison export) and SLARAFIPI-60 (FKITDEV-8787, phantom-room self-heal) — with their evidence blocks, plus the open items to resolve before the document ships. Drafted 2026-08-11.

For Agents

  • Insertion point: after the SLARAFIPI-62 - Logikai adategyezés dr issue javítása section (i.e. at the end) of Raiffeisen - Tesztelési jegyzőkönyv - VUER OSS CSS - Release 1.9.11.100.docx.
  • Word styles: section title = Heading 2, Fejlesztés / Teszteset = Heading 3, Elvárt működés = Heading 4, everything else Normal. Full shape: tesztjegyzokonyv-partner-release-document-structure.
  • The Hungarian below is final customer-facing prose — reuse verbatim, do not paraphrase. Only partner-side ticket ids appear (no FKITDEV-), as the tooling asserts.
  • Rendering is JSON-driven via /Users/levander/coding/facekom/.claude/scripts/tjk/append_release_sections.py — see tesztjegyzokonyv-generation-flow and tesztjegyzokonyv-primer-prompt.

The SLARAFIPI-60 fix covers ALREADY_HAS_ROOM only — Already authorized is deliberately NOT fixed

The Already authorized error comes from selfService:v2:register / selfService:v2:auth, and the fix intentionally preserves the socket’s authorization (customerId) — it clears only the room reference. So if the Myra client re-registers / re-auths on the same socket at restart, Already authorized can still be thrown. The ticket title names both symptoms; the delivery covers one. Say so in the section rather than letting the title imply more.

ASSRAFIPI-119 - Arcösszehasonlítások eredményeinek kigyűjtése

Fejlesztés

A partner kérése az volt, hogy egy megadott időtartamra vonatkozóan ki lehessen gyűjteni minden arcösszehasonlítás eredményét — azokat is, amelyek az előre meghatározott küszöb felett vannak, tehát different_face eredményt adnak.

A korábbi próbálkozás azért nem vezetett eredményre, mert a different_face nem tárolt státusz, hanem olvasáskor, a tárolt távolság és az érvényes küszöb összevetéséből számított eredmény. A faceComparisons táblába minden lefutott összehasonlítás euclideanDistance értéke (koszinusz-távolság, 0–2) feltétel nélkül beíródik status='success' mellett, akkor is, ha a távolság a küszöb felett van. A tárolt status csak azt jelzi, hogy az összehasonlítás lefutott-e (success), egyáltalán nem volt kiszámítható (failed), vagy még nem futott le (created).

Ehhez egy export szkript készült, amelyet üzemeltetői oldalról, új release nélkül lehet futtatni:

node customization/bin/raiffeisen-facecomparison-export.js [-c] [-n] [-p <útvonal>] [-f <flow-prefix>] <kezdő dátum> <záró dátum>
  • dátumformátum YYYY-MM-DD, legfeljebb 365 nap; időzóna-helyes napkezdet/napvég
  • -c CSV (alapértelmezés XLSX), -n ügyfélnévvel, -p export útvonal, -f flow-névprefix szűrés (pl. pion)
  • kimenet: facecomparisons_<kezdő>_<záró>.<csv|xlsx>, 0o600 engedéllyel

A riport a videochat (roomId) és az önkiszolgáló (selfServiceRoomId) ágat egyaránt lefedi. Minden sor tartalmazza a nyers távolságot és az arra a szobára érvényes küszöböket, így a számított eredmény utólag is auditálható. A different_face esetek kiszűrése ezután a Verdict oszlop szűrésével triviális.

Teszteset

1. Unit tesztek — 23 teszteset a FaceComparisonExportService-re (küszöbszintek és határértékek, küszöb-feloldás globális és szoba-szintű konfigurációból, link-típusok, flow-szűrés, ügyfélnév-feloldás, üres export):

FaceComparisonExportService
  classifyVerdict
    ✓ classifies by distance against thresholds
    ✓ treats non-success and null distance as terminal states
    ✓ uses the match tier when configured
  deriveLinkType
    ✓ maps the FK combination to a link type
  resolveGlobalThresholds
    ✓ merges stored euclideanDistances onto code defaults
    ✓ falls back to defaults when setting is absent
  resolvePerRoomThresholds
    ✓ uses the oldest config-state activity per room, merged onto global
    ✓ returns an empty map for no rooms
  loadFlowsForChunk
    ✓ queries flows by both room keys and returns raw rows
    ✓ returns an empty array when there are no rooms
  resolveFlowName
    ✓ picks the flow whose lifetime window contains the comparison time
    ✓ joins distinct names when no single window matches
    ✓ returns empty string when no flow matches the room
  getFaceComparisonsChunked
    ✓ yields chunks until an empty page, ordered by id
    ✓ prefilters by flow name when a prefix is given
    ✓ yields nothing and never queries FaceComparison when flowPrefix matches no flows
  loadCustomerNames
    ✓ returns a decrypted-name map keyed by customer id
    ✓ returns an empty map when there are no ids
  prepareReportData
    ✓ assembles rows for both link types with verdict and flow context
    ✓ emits empty string for null customerId and null for null createdAt
    ✓ returns a header-only aoa when there are no comparisons
  convertToArray / getHeaderRow
    ✓ builds an aoa with a header derived from row keys
    ✓ builds a header-only row honoring the withName flag

Test Suites: 1 passed, 1 total
Tests:       23 passed, 23 total

2. End-to-end futtatás — a tesztelés során a sorokat a valódi összehasonlító kódút állította elő (videochat:close → FaceRecognitionService.compareFaceDetections), nem előre beírt adatok; ezután a szkript exportálta őket. Egy egyező és egy nem egyező (negált leíró) összehasonlítás készült:

[5/6] Producing real faceComparison rows (videochat:close hook)
Created customer #1, room #1, flow "pion-online-verification-phase-1" #1
Created faceRecognition portrait #1 (customer-portrait), id-card #2 (id-card-front)
Mode: match (near-identical descriptor)
--- RESULT ---
faceComparison id=1 status=success euclideanDistance=0
roomId=1 customerId=1 recognitionFromId=1 recognitionToId=2

Created customer #2, room #2, flow "pion-online-verification-phase-1" #2
Created faceRecognition portrait #3 (customer-portrait), id-card #4 (id-card-front)
Mode: different (negated descriptor)
--- RESULT ---
faceComparison id=2 status=success euclideanDistance=2
roomId=2 customerId=2 recognitionFromId=3 recognitionToId=4

[6/6] Running export bin
Face comparison export finished (2 rows). File saved at /tmp/facecomparisons_2026-08-01_2026-08-11.csv

Az exportált állomány tartalma:

Face comparison ID,Compared at,Link type,Status,Distance (cosine 0-2),Verdict,Threshold perfect,Threshold probable,Room ID,Self-service room ID,Flow name,Customer ID,User ID,From image category,To image category
1,2026-08-11 11:37:58,videochat,success,0,success,0.5,0.6,1,,pion-online-verification-phase-1,1,,customer-portrait,id-card-front
2,2026-08-11 11:37:58,videochat,success,2,different_face,0.5,0.6,2,,pion-online-verification-phase-1,2,,customer-portrait,id-card-front

A második sor mutatja a lényeget: a küszöb felett lévő összehasonlítás is benne van az exportban, status=success mellett different_face eredménnyel — vagyis az adat mindig is a DB-ben volt, csak az eredmény olvasáskor számítódik.

3. Flow-szűrés — a -f pion prefixszel futtatott export ugyanezt a két sort adta vissza (a flow neve pion-online-verification-phase-1), nem illeszkedő prefix esetén pedig a szkript nem is kérdezi le a faceComparisons táblát.

Elvárt működés

A szkript a megadott időszak összes arcösszehasonlítását exportálja — videochat és önkiszolgáló ágat egyaránt —, a nyers távolsággal és az alkalmazott küszöbökkel együtt, így a different_face esetek is megjelennek, és minden eredmény visszaellenőrizhető. A futtatás új release nélkül, üzemeltetői oldalról elvégezhető.

SLARAFIPI-60 - Already authorized. Already has some kind of room error

Fejlesztés

A hiba akkor jelentkezett, amikor a kliens socket-sessionjében megmaradt egy korábbi önkiszolgáló szoba hivatkozása, miközben a hozzá tartozó szoba a szerver oldalon már lejárt. Új folyamat indításakor a selfService:v2:start az „Already has some kind of room” ellenőrzésen elakadt, így az ügyfél nem tudott új folyamatot indítani, pedig élő szobája már nem volt. Ez adta a bejelentésben szereplő „csökevény szoba” jelenséget: nem kapott feladatokat a telefon, majd az újrapróbálkozás is elakadt.

A javítás két ponton nyúl bele a folyamatba:

  1. Szoba indításakor a rendszer az „Already has some kind of room” ellenőrzés előtt lekérdezi a hivatkozott szoba hátralévő idejét. Ha a szoba már nem él, törli a socketbe ragadt szoba-hivatkozást (magát a szobát nem), és a folyamat tisztán elindul. A művelet naplózódik: SelfServiceV2 self-heal: clearing stale selfServiceRoomData for dead room <id>.
  2. Megszakításkor (selfService:v2:abort) a rendszer a megszakítás után törli a szoba-hivatkozást, így a „megszakítás → újraindítás ugyanabban a munkamenetben” forgatókönyv is elakadás nélkül lefut.

Szándékos védelem: ha a hátralévő idő lekérdezése hibára fut, vagy értelmezhetetlen választ ad (null, NaN, üres objektum), a rendszer megtartja az állapotot és nem töröl (fail-closed). Egy sikertelen lekérdezés nem bizonyítja, hogy a szoba halott — a törlés ilyenkor párhuzamos, élő szobát hozhatna létre. Lejárt szoba esetén a lekérdezés 0-t ad vissza, nem hibát, ezért ez a védelem nem zavarja a javítást.

Teszteset

1. Unit tesztek — 12 új teszteset a self-heal és az abort ágra; a teljes selfservice-v2 socket teszt-készlet sikeresen lefutott:

selfservice-v2 socket events > events > selfService:v2:start
  FKITDEV-8787 self-heal stale selfServiceRoomData
    ✓ clears stale selfServiceRoomData when getRemainingSeconds returns 0
    ✓ preserves state and throws ALREADY_HAS_ROOM when getRemainingSeconds returns a malformed response
    ✓ preserves state and throws ALREADY_HAS_ROOM when getRemainingSeconds returns NaN
    ✓ preserves state and throws ALREADY_HAS_ROOM when getRemainingSeconds fails unexpectedly
    ✓ still throws ALREADY_HAS_ROOM when the room is alive (positive remainingSeconds)
    ✓ still throws ALREADY_HAS_ROOM when remainingSeconds === 1 (room alive)
    ✓ does not call getRemainingSeconds when there is no per-socket selfServiceRoomData

selfservice-v2 socket events > events > selfService:v2:abort (FKITDEV-8787)
  ✓ calls the OSS abort RPC with the current selfServiceRoomId
  ✓ clears client.sessionData.selfServiceRoomData after successful abort
  ✓ preserves customerId after abort (only roomData is cleared)
  ✓ regression: start → abort → start succeeds (does not throw ALREADY_HAS_ROOM)
  ✓ does not clear selfServiceRoomData if the abort RPC rejects

Test Suites: 1 passed, 1 total
Tests:       76 passed, 76 total

A kiemelt eset a regression: start → abort → start succeeds — pontosan az a sorrend, amely a bejelentés előtt „Already has some kind of room” hibával elakadt.

2. Lejárt szoba és élő szoba elkülönítése — a tesztek igazolják, hogy a rendszer csak akkor törli a ragadt hivatkozást, ha a szoba bizonyítottan lejárt (remainingSeconds érvényes szám és < 1). Élő szoba esetén (beleértve az 1 határértéket) továbbra is elutasítja az indítást, tehát a javítás nem nyit utat párhuzamos szobák létrehozására.

3. Mobil forgatókönyvek — a jelenség csak akkor áll elő, ha a mobilalkalmazás ugyanazt a socketet használja tovább; az alkalmazás teljes bezárása/újraindítása új socketet nyit, így azzal a hiba nem reprodukálható. A két végponti forgatókönyv:

  • A) Lejárt szoba helyreállítása: folyamat indítása → a szoba járjon le (az alkalmazás bezárása nélkül) → alkalmazáson belüli Újraindítás. Elvárt: friss folyamat, megjelennek a feladatok, az első fénykép átmegy.
  • B) Megszakítás → újraindítás: indítás → alkalmazáson belüli Mégse/megszakítás → újraindítás ugyanabban a munkamenetben. Elvárt: tisztán elindul, nincs „Already has some kind of room”.

Szerveroldali ellenőrzés mindkét esetben: docker logs -f vuer_css | grep -i "self-heal".

Elvárt működés

Ha a kliens socket-sessionjében lejárt szoba hivatkozása maradt, az új folyamat indítása nem akad el: a rendszer törli a ragadt hivatkozást, és az ügyfél-ügymenet-szoba összerendelés az újonnan indított önkiszolgáló szobában megtörténik. Élő szoba esetén az indítás továbbra is elutasításra kerül, párhuzamos szoba nem jön létre.

Megjegyzések a jegyzőkönyv kitöltéséhez

  1. A javítás az ALREADY_HAS_ROOM (phantom szoba) útvonalra vonatkozik. Az Already authorized hibaüzenet a selfService:v2:register / selfService:v2:auth végpontokból származik, és a javítás szándékosan megtartja a socket authorizációját (customerId) — csak a szoba-hivatkozást törli. Ha a Myra kliens az Újraindításnál újra register/auth-ot hív ugyanazon a socketen, az Already authorized továbbra is jelentkezhet. A mobil forgatókönyvek (A/B) végigvitele ezt zárná le véglegesen.
  2. A mobil forgatókönyvek (A/B) még nem futottak le — valódi Raiffeisen Myra kliens kell hozzá. A fenti tesztbizonyítékok szerveroldaliak.
  3. A Bevezetés szakasz dátuma 2026.08.10. — ha a fenti tesztek friss futtatása bekerül, érdemes 2026.08.11.-re módosítani vagy a szakaszban jelezni.
  4. A 8827 export küszöbei a lokális teszten a kód alapértelmezései (0.5 / 0.6). A Raiffeisen deploymentben érvényes perfect=0.55 felülírást a szkript a valódi konfigurációból olvassa; ez korábban a Raiffeisen dev környezetben igazolódott.
  5. Formázási hiba a meglévő vázlatban: a SLARAFIPI-59 - Girinfo feldolgozás issue szakaszban a Fejlesztés alatti két bekezdés tévesen Heading 3 / Heading 2 stílust kapott (ezért bekerül a tartalomjegyzékbe), és a szakasz előtt két üres Heading 2 bekezdés áll. Érdemes Normal stílusra állítani és az üres címsorokat törölni.
  6. A SLARAFIPI-62 - Logikai adategyezés dr issue javítása szakasz Fejlesztés és Teszteset blokkja üres a vázlatban.

Graph View

Backlinks