---
title: Front, ktorý bol prázdny dvadsaťjeden dní
type: failure
level: L2
status: live
revision: 1
updated: 2026-08-14
systemVersion: 4.2
authoring: machine-translated
tags: [tooling, data-integrity, silent-failure]
rating: 8.25
ratingAxes: useful 8 · evidence 9 · pull 8 · original 8 · form 8
ratingKind: derived
source: pattern log triage, 2026-07-27
---

# Front, ktorý bol prázdny dvadsaťjeden dní

_Written 2026-08-14 · last verified 2026-08-14 · system v4.2 · live_

**TL;DR** — Triage skript hlásil prázdny front po dobu 21 dní. Do zdrojovej tabuľky pribudli dva stĺpce a skript ich naďalej čítal podľa pozície, takže zachytával stĺpec vlastníka a porovnával ho s hodnotami statusu — a nikdy sa nezhodoval. Nič nespadlo s chybou, pretože pozičné čítanie širšej tabuľky je stále platné čítanie.

## Príznak

Týždenný triage skript hlásil prázdny front. Žiadne položky nevyžadovali kontrolu. Trvalo to **21 dní**, čo pôsobilo skôr ako pokojné obdobie než ako porucha — fronty sa občas naozaj vyprázdnia.

Neboli prázdne. Keď sa tabuľka napokon otvorila ručne, obsahovala 20 otvorených položiek oproti prahovej hodnote 10, pričom niekoľko z nich bolo staršie ako dva týždne.

## Príčina

Zdrojom je markdown tabuľka. Skript čítal polia **podľa pozície**.

O dva týždne skôr do tabuľky pribudli dva nové stĺpce v strede. Každé pole za bodom vloženia sa posunulo o dve miesta doprava. Skript naďalej čítal ten istý index, ktorý teraz obsahoval pole vlastníka, a porovnával jeho obsah so zoznamom platných hodnôt statusu.

Nič sa nezhodovalo. Prázdna množina výsledkov je legitímny, nenápadný výstup, takže ju skript vrátil bez akéhokoľvek varovania.

Pri tej istej kontrole vyšla najavo aj druhá chyba: bunky obsahujúce znak zvislej čiary s escapovaním posúvali stĺpce vlastného riadku nezávisle od hlavičky, čo tichým spôsobom vyraďovalo jeden konkrétny záznam z každého behu už dlhšie, než dokázal ktokoľvek datovať.

## Náklady

Tri týždne fungovania governance slučky, o ktorej si všetci mysleli, že beží. Položky nezmizli — starli, a tie, na ktorých záležalo, bolo treba znovu prejsť triage od začiatku voči kontextu, ktorý sa medzičasom posunul ďalej.

Nákladnejšia je dôvera. Len čo sa preukáže, že plánovaný report klamal, každý predchádzajúci pokojný týždeň sa stáva podozrivým a neexistuje spôsob, ako spätne zistiť, ktoré z nich boli skutočne v poriadku.

> Trieda zlyhania: **oprava naviazaná na formát súboru, ktorý nevlastní, sa pri refaktoringu tohto súboru ticho odviaže.**

## Náprava

Dve zmeny, obe malé.

Skript teraz číta **podľa názvu hlavičky**, nie podľa pozície. Pridanie, odstránenie alebo zmena poradia stĺpcov už nemôže pole spod neho vysunúť.

A **hlásite zlyháva**. Prázdny front je teraz odlíšený od frontu, ktorý sa nepodarilo spracovať:

> `queue: 0 items (parsed 24 rows, 9 columns, header matched)` — oproti tvrdej chybe, ak očakávané hlavičky chýbajú.

Chyba s escapovanou zvislou čiarou bola opravená v tom istom kroku, a to rozdeľovaním iba na neescapovaných oddeľovačoch.

## Prevencia

Zovšeobecniteľné pravidlo sa týka **prázdnych výsledkov, nie markdownu**. Prázdny výstup je najnebezpečnejšia podoba, akú report môže mať, pretože sa nedá odlíšiť od úspechu a práve ju produkuje takmer každá chyba parsovania.

Preto: každá plánovaná kontrola, ktorá môže vrátiť nulu, musí zároveň nahlásiť, čo skúmala. Počet riadkov, počet stĺpcov, či bola nájdená očakávaná schéma. Nula s pôvodom je informácia; holá nula je predpoklad prezlečený za číslo.

A tam, kde jeden program číta súbor vlastnený iným programom, je väzba založená na **názvoch**, nikdy na pozíciách — pozícia je sľub, ktorý druhý súbor nikdy nedal.