Pagkahuli sa mga App na Nag-crash Pagkatapos Mag-publish

Noong Setyembre 25, tatlong publish ang minarkahang matagumpay kahit nag-crash ang API ng app ilang segundo sa bawat boot. Dahil "nagtagumpay" sila, walang tumakbong rollback; pinabagsak sila ng isang background check pagkalipas ng ilang minuto, at napunta sa 404 ang buong site. Binibilang ng health check ang mga crash sa event list ng hosting platform, na tanging huling limang event lang ang kayang hawakan kada makina, kaya kapag paulit-ulit ang crash, nananatiling puno ang listahan at hindi tumataas ang bilang. Ngayon, ikinukumpara na nito ang oras ng pinakabagong crash, at ang publish na paulit-ulit ang crash ay pumapalya at ibinabalik ang nakaraang bersyon.

Ano ang hinihintay ng publish

Kapag nag-publish ka ng app na may backend sa Mythex, ang bagong bersyon ay ilalabas sa mga makina ng hosting platform namin, at magpapasya ang health check kung nag-live ang publish o pumalpak. Kung pumalpak, ibinabalik ng rollback ang nakaraang bersyon.

Ang mahirap dito ay hindi pareho ang "nagsimula" at ang "nagseserbisyo". Minamarkahan ng platform ang makina bilang nagsimula sa sandaling umangat ito. Ang app na nag-crash ilang segundo pagkatapos ng boot ay agad na nire-restart, at ilang sandali pa, binabasa itong muli bilang nagsimula. Kaya unti-unting dumami ang mga layer ng health check:

1. Tumingin nang dalawang beses. Pagkatapos basahin ang makina bilang nagsimula, maghintay sandali at tumingin ulit. Kadalasang pumapalya ang ikalawang pagtingin kapag nag-crash sa boot.
2. Bantayan ang crash loop. Kung iniulat ng platform na paulit-ulit na nag-crash ang makina at sumuko na ito sa pag-restart, pumalpak.
3. Bilangin ang mga crash mula nang magsimula ang publish. Maaaring dumaan sa restart ang dalawang pagtingin na "nagsimula". Kaya kung may anumang crash mula nang magsimula ang publish na ito, tumingin ng ikatlong beses; kung mas marami ang crash kaysa sa nakaraang pagtingin, hindi nananatiling tumatakbo ang app.

Ang ikatlong check ang pumalpak dito.

Bakit nanatiling pareho ang bilang

Galing ang impormasyon ng crash sa event list ng bawat makina: mga start, exit, at restart. Tanging ang huling limang event kada makina ang itinatago ng platform.

Isipin ang app na nag-crash 2.5 segundo pagkatapos ng bawat boot, gaya ng isa sa mga ito. Bawat ikot ay nagdaragdag ng isang crash at isang start. Pagkalipas ng ilang ikot, puno na ang listahan. Mula noon, bawat bagong event ay nagtutulak palabas ng isang lumang event. Dumudulas ang listahan, pero laging halos pareho ang halo nito: ilang crash, ilang start.

Kaya ang "ilang crash mula nang magsimula ang publish" ay nagbabalik ng parehong numero sa bawat pagtingin. Nakita ng ikalawang pagtingin, sabihin nating, dalawang crash. Dalawa rin ang nakita ng ikatlong pagtingin, iba-ibang crash, pero parehong bilang. Nagpasya ang check na tumigil na ang pag-crash, at pinasa ang publish.

Nangyari ito nang tatlong beses noong Setyembre 25, sa dalawang app. Sa bawat pagkakataon:

• minarkahang live ang publish,
• walang tumakbong rollback, dahil walang pumalpak,
• ang reconciler namin, isang background job na sumusuri sa mga deployment pagkatapos nito, ay pinabagsak ang deployment pagkalipas ng ilang minuto,
• at bumalik sa 404 ang buong site.

Ang publish na pumapalya sa tamang oras ay naibabalik: ibinabalik ng rollback ang nakaraang bersyon. Ang publish na pumapalya nang ilang minuto pagkatapos ideklarang tagumpay ay nilaktawan na ang rollback nito.

Paano namin ito natuklasan

Inulit namin ito nang lokal: kumuha ng gumaganang API, hinayaang matulog, at pagkatapos ay nag-republish gamit ang pagbabagong nag-crash sa boot. Minarkahan ng health check na live ito.

Tugma ito sa nangyari sa production: sa bawat isa sa tatlong publish, namatay ang app ilang segundo sa bawat boot, pero hindi tumaas ang bilang ng crash na ikinukumpara ng check sa pagitan ng mga pagtingin.

Ang ayos: ikumpara ang pinakabagong crash, hindi ang bilang

Sa halip na bilangin ang mga crash, ngayon ay tinitingnan na ng check ang oras ng pinakabagong crash mula nang magsimula ang publish.

Kung ang ikalawang pagtingin ay nagpapakita ng anumang crash mula nang magsimula ang publish, maghihintay ang check at titingin ng ikatlong beses. Kung ang pinakabagong crash sa ikatlong pagtingin ay mas huli kaysa sa pinakabagong crash sa ikalawa, nag-crash ulit ang makina sa pagitan. Hindi ito nananatiling tumatakbo, at pumapalya ang publish na may mensaheng paulit-ulit na nag-crash ang makina mula nang mag-publish at nagre-restart pa rin ito.

Gumagana ito anuman ang haba ng event list. Maaaring itago ng sliding window na limang event kung ilan ang crash, pero hindi nito maitatago na may bagong nangyari, dahil laging nananatili ang pinakabagong event.

Sa pagbabagong ito, tama nang kumilos ang lokal na pag-uulit: pumapalya ang publish, at naibabalik ang nakaraang image. May test din na ginagaya ang asal ng platform (bawat pagtingin ay nagdaragdag ng crash at start at pinuputol ang listahan sa lima), at sinusuri nitong pumapalya ang hatol, hindi pumapasa.

Ang natutunan namin

• Alamin ang hugis ng data na binibilang mo. Nawawalan ng kahulugan ang bilang sa capped na listahan kapag puno na ito. Hindi nakatago ang cap; hindi lang namin dinisenyo ang check ayon dito.
• Mas mainam ang "may bago bang nangyari?" kaysa "ilan ang nangyari?" Nananatili ang pinakabagong timestamp kahit putulin ang listahan. Hindi nananatili ang kabuuan.
• Mas masama ang huling pagkabigo kaysa sa maagang pagkabigo. Hindi nakapipinsala ang parehong sirang build kung pumalpak ang publish at nag-rollback, pero nagpapabagsak ng site kung idineklarang tagumpay muna ito.
• Mag-reproduce sa totoong kondisyon. Kailangan ng bug ang makinang nakapag-crash na nang sapat para mapuno ang event list nito. Hindi ito lilitaw sa isang mabilis na crash lang sa test.

Kasama ng ayos na ito ang isa pang ayos mula sa parehong araw, na tiniyak na ibinabalik ng rollback ang lumang bersyon sa halip na burahin ito: ang pumalpak na republish ay hindi kailanman bumubura ng gumaganang backend. Kung pumapalya ang sarili mong app sa publish dahil nag-crash ito sa pagsisimula, magandang simulan sa troubleshooting ng publish sa docs at sa gabay namin tungkol sa pag-debug ng app na ginawa ng AI.