Opäť sa mi potvrdilo, ako jednoducho sa dá zamotať, keď hľadáte riešenie na nejaký konkrétny problém. Na prvý pohľad banálny problém pri testovaní galérie (konkrétne pri nahrávaní obrázkov) mi zbytočne ubral 2 dni zo života.
Tu to ešte fungovalo
Počas vývoja galérie som používal set niekoľkých obrázkov s rôznymi vlastnosťami, teda extrémne veľké/ malé obrázky, rôzne formáty, a podobne. Tiež som testoval validáciu pre prípad, že sa užívateľ pokúsi nahrať súbory, ktoré nie sú obrázkom.
Do tohto momentu všetko prebiehalo bezproblémovo.
Odtiaľ to prestalo fungovať
Po dokončení a finálnom testovaní v produkčnej verzii som začal používať viacero obrázkov a pokúšal sa nasimulovať správanie bežného používateľa. Obrázky som preto získaval z rozličných fotobánk, až som narazil na zdroj X = zdroj môjho problému.
Žiaden z obrázkov zo zdroja X sa mi nepodarilo nahrať do galérie. Pritom iné obrázky, z iných zdrojov, boli úplne v pohode.
1. Chybný predpoklad
Myslel som si, že problémom sú samotné obrázky z tohto zdroja. Tak som všetku svoju pozornosť sústredil na analyzovanie daných obrázkov.
Ukázalo sa, že obrázky zo zdroja X predsa len nie sú úplne štandardné. Viaceré analytické nástroje mi takisto potvrdili, že ich MIME TYPE je iba všeobecný application/octet-stream.
Úprimne som netušil, prečo mi to vyhodnotilo ako všeobecný octet-stream. Rozhodne som očakával MIME TYPE image/jpeg, resp. image/png, alebo niečo podobné...
Problém s MIME TYPMI mi však pomohol odhaliť zaujímavosť. Symfony framework síce MIME TYPE v procese validácie obrázkových súborov využíva, avšak v zozname podporovaných MIME TYPOV chýba image/svg+xml pre svg formát.
Validný je len image/svg+xml typ.
Ide o to, že niektoré svg súbory sú minifikované a ich obsah začína priamo tagom <svg>. Takýto súbor má MIME TYPE image/svg - čiže neprejde validáciou, a tým pádom nie je vyhodnotený ako obrázok.
Pre Symfony musí validný svg súbor začínať tagom <?xml version="1.0" encoding="iso-8859-1"?>, tak ako si to vyžaduje syntax well-formed XML dokumentov.
2. Chybný predpoklad
Do procesu hľadania chyby sa v jednom momente zapojil aj kolega, ktorý poznamenal, že na inom zariadení sa chyba neprejavila. To ma priviedlo naspäť na začiatok a napadlo mi, že problém bude práve v rozdielnom vývojovom prostredí.
Iná verzia PHP
Cely zúfalý a nasr... nahnevaný som sa teda rozhodol, že zmením vývojové prostredie a verziu PHP. Jediným relevantným zdrojom pre Windows knižnice php je https://windows.php.net/download - čo je v podstate stránka, na ktorej funguje celý svet a prakticky aj každý developer (okrem Apple pozitívnych developerov :) .
...a samozrejme, že práve vtedy, keď som to potreboval ja, museli mať na stránke výpadok!
Celý vesmír sa proti mne spikol v duchu: choď domov, svet ťa nemá rád. Dnes to aj tak neopravíš.
Po riadnej chvíľke hľadania správnej verzie som konečne zreplikoval prostredie. A čo som zistil?
Že tam chyba nie je.
#damn #dogday
Konečne správna stopa
Keď som sa už vracal k pôvodnej teórii, že chyba je v obrázkoch, zapojil sa do toho našťastie ďalší kolega. Ten síce chybu potvrdil, no v jednom z mnohých prípadov sa mu obrázok podarilo nahrať.
Začal som tušiť, že chyba predsa len bude v nastavení aplikácie a prostredia.
V čom bol teda problém?
- Niektoré funkcie manipulovania s obrázkami neboli správne ošetrené pre prípad, že dôjde ku zlyhaniu (Error Exception)
- Nesprávne bolo aj logovanie týchto výnimiek
- Problémom (prekvapivo) nebola veľkosť obrázkov na disku, ale ich extrémne vysoké rozlíšenie. To znamená, že spracovanie týchto obrázkov si vyžadovalo oveľa väčšie zdroje na pamäť.
A riešenie?
Riešením bolo rozumne navýšiť alokovanú pamäť, zoptimalizovať spracovanie obrázkov, a hlavne - ošetriť výnimky, ktoré môžu vzniknúť počas behu aplikácie.
Najhoršie na tom všetkom ale bolo to, že sa z navonok banálneho problému stal prúser na dva dni. A to len kvôli tomu, že som venoval pozornosť nesprávnym veciam, ktoré so samotným problémom nakoniec vôbec nesúviseli. A tiež kvôli súhre náhod, na ktoré som pri debugovaní narazil.
#gameover #dogday
Pridať komentár