Kdysi dávno existoval číselník chyb, kde chyby byly rozděleny do kategorií
"Informace pro uživatele", "Narušení aplikační logiky klientským požadavkem" apod.
V kategorii "Informace pro uživatele" byly kódy, které neznamenaly chybu, ale pouze
podávaly doplňující informaci o výsledku operace. Tato kódy byly všechny menší než 100
a při těchto kódech aplikace zpravidla mohla normálně dokončit zpracování výsledku požadavku
(třeba kód 0001: Úspěšně zaznamenáno, nebo kód 0003: Výběr zadán přílič obecně, výsledků
je příliš mnoho" který se objevil v případech, kdy systém omezil počet nalezených datových
schránek při příliš obecných kritériích hledání). Nyní se však objevil další kód vrácený při požadavku
na stažení zprávy, která již na serveru není, a to 0005, Nepodařilo se získat časové razítko pro značku
MV v podpisu datové zprávy. Tento kód však rozhodně nelze považovat pouze za informační,
neboť znamená selhání požadavku a aplikace nemůže dále normálně pokračovat. Je možné,
že moje interpretace toho, že informační kódy jsou do kódu 0099, je pouze můj dojem, protože skutečně
takto to nikde nebylo závazně publikováno. Čili mám dotaz - jak poznám který kód je pouze informační
a mohu tedy zpracování požadavku normálně dokončit?
36.1 Re: Číselník chyb, pravidlo pro zjištění vážnosti chyby
admin 17.01.2017 11:35Dobrý den.
Číselník existuje stále, na tomto webu je aktuální verze ke stažení.
Stavy 0001-00xx jsou opravdu stavy informační. Stav 0005 na testovacím prostředí říká, že zpráva byla sice úspěšně stažena, ale nebyla opatřena časovým razítkem. Na produkci není zatím zapnuto, protože server časového razítka nestíhá razítovat, a Pošta proto posiluje infrastrukturu.
Bohužel minulý měsíc se část té funkcionality omylem objevila i na produkčním prostředí a způsobovala chyby, které popisujete vy a další níže v této diskuzi. To, co popisujete nyní by ukazovalo se, že místo některých standardních chyb se vrací tento nesprávný kód. Pátráme po příčině.
Jan Šíma
36.2 Re: Číselník chyb, pravidlo pro zjištění vážnosti chyby
admin 17.01.2017 11:35Dobrý den.
Na základě vašeho podnětu jsme provedli různé testy na produkčním prostředí a nezdá se nám příliš pravděpodobné, že by se mohla vyskytnout chyba 0005. Při pokusu o stažení zprávy z archivu dostáváme správnou chybu (myslím 1219). Nemluvíte o testovacím prostředí?
Jan Šíma
36.3 Re: Číselník chyb, pravidlo pro zjištění vážnosti chyby
admin 17.01.2017 11:35Popisovaný kód 0005 se mi vracel v pondělí 20.12.2010 při pokusu o stažení staré a na serveru neexistující zprávy v TESTOVACÍM PROSTŘEDÍ (omlouvám se že jsem to hned nenapsal, ale předchozí chyba se objevovala na obou prostředích stejně, tak jsem tak nějak předpokládal že to bylo opraveno stejně). Na ostré větvi jsem to v ten den neověřil. Dnes 21.12.2010 se při pokusu o stažení staré zprávy už korektně objeví kód 1219 "Zpráva 209730 pro (id schranky) není v databázi", a to na ostré i testovací větvi. Děkuji.
36.4 Re: Číselník chyb, pravidlo pro zjištění vážnosti chyby
admin 17.01.2017 11:35Jen abych vysvětlil ten informačí stav 0005 (nyní na TESTOVACÍM prostředí): při stažení podepsané datové zprávy se do podpisu vloží časové razítko, způsobem popsaným v RFC 3161 a v RFC 3852. Protože se to děje synchronně, musí existovat stav, kdy se razítko nepodaří "rychle" (v současnosti je to 5 vteřin) získat. To bude právě stav 0005 a zpráva se stáhne bez razítka. Pro mnohé účely to stačí (stejné jako dnes), a pokud ne, tak se musí stažení opakovat později.
Pro informaci - při vytváření zpráv toto nastat nemůže, protože se razítkuje asynchronně, maximálně naroste fronta zpráv čekajících ve stavu 1 (a na Portále se indikátor zatížení posune do červené). Pak čas podání zprávy se může lišit i o minuty od času dodání.
Kdy bude nasazeno na PRODUKČNÍM prostředí, není vůbec jasné, záleží na poskytovateli razítek, až potvrdí připravennost s nárůstem počtu razítek o cca 600 000 denně. Je možná i varianta, že se to nenasadí nikdy, proto nedoporučujeme zatím něco programovat. Naopak doporučujeme otestovat stahování zpráv na TESTu, aby se potvrdila kompatibilita Vaší aplikace s tímto novým formátem (zatím pouze jeden vývojář ohlásil problém, ale vyřešilo se to novou verzí jeho knihovny pro práci s podpisy).
Jan Šíma
36.5 Re: Číselník chyb, pravidlo pro zjištění vážnosti chyby
admin 17.01.2017 11:35OK, děkuji za vysvětlení chyby 0005. Já jsem se původně domníval, že ta chyba oznamuje (na testovacím prostředí), proč nešla stáhnout stará a na serveru neexistující datová zpráva. Teď už jsem moudřejší :-)