Az „unexpected token” üzenet ritkán mondja meg a teljes okot. A kliens JSON-t várt, de kaphatott HTML bejelentkezési oldalt, plain-text stack trace-t, üres választ vagy egy félbeszakadt dokumentumot. Máskor a szintaxis helyes, de az adatot kétszer serializálták vagy rossz charsettel dekódolták. A hatékony vizsgálat ezért a tényleges bájtokkal, státusszal és fejlécekkel kezdődik.

A parser előtt ellenőrizni kell a HTTP választ

Reverse proxy 502-es HTML oldalt, auth middleware redirectet, rate limiter sima szöveget adhat. Ha a kliens mindent automatikusan JSON-ként parsol, az első idegen karakter elfedi az eredeti hibát.

A diagnosztika rögzítse a státuszt, Content-Type-ot, hosszt és rövid redaktált mintát. Teljes érzékeny body vagy token ne kerüljön általános logba.

Az első hibás token gyakran csak következmény

A parser vesszőre, zárójelre vagy inputvégre mutathat, miközben az igazi hiba korábbi hiányzó idézőjel vagy escape nélküli newline. A dokumentum formázása és az offset környezetének megjelenítése többet segít egyetlen karakternél.

Nagy payloadból biztonságos, reprodukálható fixture készüljön, ne produkciós személyes adat kerüljön ticketbe.

A JSON szigorúbb a JavaScript objektumnál

A kulcsok és stringek kettős idézőjelet igényelnek. Komment, trailing comma, undefined, NaN és Infinity nem része a szabványnak. Egy lazább konfigurációs parser által elfogadott fájl más környezetben elbukhat.

A producer könyvtári serializert használjon, ne kézi string-összefűzést. A könyvtár helyesen escape-eli az idézőjelet, backslasht és vezérlőkaraktert.

A dupla serializáció stringet készít objektum helyett

Ha egy már kész JSON szöveg újra átmegy a serializeren, a kliens backslash-ekkel teli stringet kap. Egy parse csak szöveget ad vissza, a második objektumot.

A kliensoldali második parse nem jó javítás, mert helyes válasznál elromlik. Minden határnak tudnia kell, objektummodellt vagy kész JSON bájtokat fogad-e.

A csonka átvitel szintaktikai hibának látszik

Timeout, process crash vagy rossz Content-Length félbeszakíthatja a választ. A parser váratlan inputvéget jelez, bár a serializer eredetileg helyes struktúrát kezdett készíteni.

Össze kell vetni a deklarált és fogadott hosszt, proxy logot és request időt. Írási művelet retry-jához idempotency key szükséges.

A charset a parsolás előtt rongálhat

A webes JSON alapértelmezett gyakorlata az UTF-8. Hibás dekódolás replacement karaktert vagy érvénytelen sorozatot hozhat létre. BOM és történelmi encoding eltérő parser-viselkedést okozhat.

A szerver egységes UTF-8-at és helyes Content-Type-ot bocsásson ki. Hibakereséskor a framework által készített string előtt a raw bytes is vizsgálandó.

A vezérlőkaraktereket escape-elni kell

Új sor, tab és más control character nem kerülhet tetszőlegesen stringbe. Log- vagy CSV-részlet kézi beillesztése gyakran itt törik el.

A megoldás nem feltétlenül a karakter eltávolítása. A serializer biztonságosan megőrzi a jelentést megfelelő escape szekvenciával.

A duplikált kulcs kétértelmű

Egy dokumentum ugyanazt a property nevet többször is tartalmazhatja. Egy parser az elsőt, másik az utolsót tartja meg, harmadik elutasítja. A security layer és a business logic így más adatot láthat.

Megbízhatatlan határon a duplikátumot célszerű elutasítani. A canonical szabály legyen azonos az aláírás és a feldolgozás számára.

Az érvényes JSON még nem érvényes kérés

A parser betöltheti az objektumot, miközben mező hiányzik, rossz típusú vagy tartományon kívüli. A szintaxis, schema és business validáció három külön lépés.

A hiba adja meg a mező útvonalát és az elvárt szabályt. Egy formailag helyes dátum még lehet tiltott múltbeli időpont.

A streaming parser részleges feldolgozást hozhat létre

Nagy dokumentumnál tokenenként vagy elemenként lehet haladni, ami csökkenti a memóriát. A hiba azonban a stream közepén érkezhet, amikor már történt side effect.

Importhoz staging, tranzakció vagy checkpoint modell kell. Queue message csak a teljes szintaktikai és sémaellenőrzés után nyugtázható.

A hibás input logolása legyen korlátozott

A teljes body jelszót, tokent vagy személyes adatot tartalmazhat. Biztonságosabb request ID-t, endpointot, méretet, parser offsetet és rövid redaktált környezetet tárolni.

A redakciónak malformed JSON esetén is működnie kell, ezért byte-level korlát és maszkolás szükséges a structured logger előtt.

A serializer is elbukhat válaszküldés közben

A szerver elküldheti a 200-as fejléceket, majd érvénytelen UTF-8 vagy nem támogatott érték miatt leállhat. A kliens csonka JSON-t kap, a státusz már nem módosítható.

Kritikus választ érdemes a fejlécek commitja előtt serializálni vagy validálni. A serialization failure külön metrika legyen a hálózati megszakítástól.

A reprodukciónak ugyanazon az útvonalon kell mennie

Online validatorban a kimásolt string lehet helyes, miközben a hiba tömörítésnél, proxytranszformációnál vagy kliensoldali dekódolásnál keletkezik. Az integrációs teszt ugyanazt a HTTP láncot, charsetet és serializert használja.

A jó diagnosztika a transporttól halad a szintaxis, séma és domén felé. Megtalálja az első réteget, ahol az elvárás eltér, és ott javítja a transzformáció tulajdonjogát.

A kompresszió és chunked átvitel külön hibaforrás

A proxy helyesen láthat tömörített bájtokat, miközben a kliens dekompresszió után hibás adatot kap. Sérült gzip stream, rossz Content-Encoding vagy köztes réteg által újratömörített válasz parse errornak látszhat. A vizsgálatnak mind a wire formát, mind a kicsomagolt bodyt ellenőriznie kell.

Chunked átvitel esetén egy hiányzó utolsó chunk vagy idő előtti kapcsolatbontás csonka dokumentumot eredményezhet Content-Length nélkül is. A HTTP kliens könyvtár hibajelzését nem szabad elnyomni és kizárólag JSON hibává alakítani.

A produkciós metrika segít megkülönböztetni az okokat

Külön számláló kell content-type mismatchre, transport truncationre, UTF-8 hibára, syntax errorra, schema failure-re és business rejectionre. Egyetlen „invalid payload” metrika nem mutatja meg, melyik csapatnak kell reagálnia.

A parser offset, szolgáltatásverzió és upstream azonosító segít összekapcsolni az eseményeket. A magas kardinalitású vagy érzékeny payload ne kerüljön metric labelbe; request ID-n keresztül kontrollált logból legyen visszakereshető.