పబ్లిష్ అయిన వెంటనే క్రాష్ అయ్యే యాప్‌లను పట్టుకోవడం

సెప్టెంబర్ 25న, మూడు పబ్లిష్‌లు విజయవంతమైనవిగా గుర్తించబడ్డాయి, అయినప్పటికీ యాప్ యొక్క API ప్రతి బూట్‌లోనూ సెకన్ల తర్వాత క్రాష్ అయింది. అవి “విజయవంతమయ్యాయి” కాబట్టి రోల్‌బ్యాక్ నడవలేదు; కొన్ని నిమిషాల తర్వాత ఒక బ్యాక్‌గ్రౌండ్ చెక్ వాటిని విఫలంగా గుర్తించింది, మరియు మొత్తం సైట్ 404 కు వెళ్లింది. హెల్త్ చెక్ హోస్టింగ్ ప్లాట్‌ఫామ్ ఈవెంట్ జాబితాలో క్రాష్‌లను లెక్కిస్తోంది — అది ప్రతి మెషీన్‌కు చివరి ఐదు ఈవెంట్‌లను మాత్రమే ఉంచుతుంది, కాబట్టి క్రాష్ లూప్ దాన్ని నింపుతుంది, మరియు లెక్క ఎప్పటికీ పెరగదు. ఇప్పుడు అది బదులుగా తాజా క్రాష్ యొక్క సమయాన్ని పోలుస్తుంది, మరియు క్రాష్-లూప్ అయ్యే పబ్లిష్ విఫలమవుతుంది మరియు మునుపటి వెర్షన్‌ను పునరుద్ధరిస్తుంది.

పబ్లిష్ దేని కోసం వేచి ఉంటుంది

మీరు Mythex లో బ్యాకెండ్ ఉన్న యాప్‌ను పబ్లిష్ చేసినప్పుడు, కొత్త వెర్షన్ మా హోస్టింగ్ ప్లాట్‌ఫామ్‌లోని మెషీన్‌లపై రోల్ చేయబడుతుంది, మరియు ఒక హెల్త్ చెక్ పబ్లిష్ లైవ్ అయిందా లేదా విఫలమైందా అని నిర్ణయిస్తుంది. విఫలమైతే, మునుపటి వెర్షన్‌ను తిరిగి పెట్టడానికి రోల్‌బ్యాక్ నడుస్తుంది.

కఠినమైన భాగం ఏమిటంటే “ప్రారంభమైంది” అంటే “సర్వ్ చేస్తోంది” కాదు. మెషీన్ పైకి లేవగానే ప్లాట్‌ఫామ్ దాన్ని ప్రారంభమైనదిగా నివేదిస్తుంది. బూట్ అయిన ఒక సెకనులో క్రాష్ అయ్యే యాప్ వెంటనే రీస్టార్ట్ అవుతుంది, మరియు కొంచెం తర్వాత అది మళ్లీ ప్రారంభమైనదిగా కనిపిస్తుంది. కాబట్టి హెల్త్ చెక్ కాలక్రమేణా కొన్ని పొరలు పెరిగింది:

1. రెండుసార్లు చూడండి. ఒక మెషీన్ ప్రారంభమైనదిగా కనిపించిన తర్వాత, కొద్దిసేపు వేచి ఉండి మళ్లీ చూడండి. బూట్‌లో క్రాష్ అయితే తరచుగా రెండవ చూపులో విఫలమవుతుంది.
2. క్రాష్ లూప్‌ల కోసం చూడండి. ప్లాట్‌ఫామ్ ఒక మెషీన్ పదే పదే క్రాష్ అయిందని, మరియు దాన్ని రీస్టార్ట్ చేయడం ఆపేసిందని నివేదిస్తే, విఫలమవ్వండి.
3. పబ్లిష్ మొదలైనప్పటి నుండి క్రాష్‌లను లెక్కించండి. రెండు “ప్రారంభమైంది” చూపులు ఒక రీస్టార్ట్‌ను దాటవచ్చు. కాబట్టి ఈ పబ్లిష్ మొదలైనప్పటి నుండి ఏ క్రాష్ జరిగినా, మూడవసారి చూడండి; మునుపటి చూపు కంటే ఎక్కువ క్రాష్‌లు ఉంటే, యాప్ స్థిరంగా ఉండటం లేదు.

ఇక్కడ విఫలమైనది మూడవ తనిఖీ.

లెక్క ఎందుకు అలాగే ఉండిపోయింది

క్రాష్ సమాచారం ప్రతి మెషీన్ యొక్క ఈవెంట్ జాబితా నుండి వస్తుంది: ప్రారంభాలు, నిష్క్రమణలు, రీస్టార్ట్‌లు. ప్లాట్‌ఫామ్ ప్రతి మెషీన్‌కు చివరి ఐదు ఈవెంట్‌లను మాత్రమే ఉంచుతుంది.

ఒక యాప్ ప్రతి బూట్‌లోనూ 2.5 సెకన్ల తర్వాత క్రాష్ అవుతుందని ఊహించండి, ఒకటి అలా చేసింది. ప్రతి సైకిల్ ఒక క్రాష్ మరియు ఒక ప్రారంభం జోడిస్తుంది. కొన్ని సైకిళ్ల తర్వాత, జాబితా నిండిపోతుంది. అప్పటినుంచి, ప్రతి కొత్త ఈవెంట్ ఒక పాత ఈవెంట్‌ను బయటకు నెడుతుంది. జాబితా ముందుకు జారుతుంది, కానీ అది ఎప్పుడూ దాదాపు ఒకే మిశ్రమాన్ని కలిగి ఉంటుంది: రెండు క్రాష్‌లు, రెండు ప్రారంభాలు.

కాబట్టి “పబ్లిష్ మొదలైనప్పటి నుండి ఎన్ని క్రాష్‌లు” అనేది ప్రతి చూపులోనూ ఒకే సంఖ్యను ఇచ్చింది. రెండవ చూపు, చెప్పండి, రెండు క్రాష్‌లు చూసింది. మూడవ చూపు కూడా రెండు చూసింది — వేరే క్రాష్‌లు, కానీ అదే లెక్క. తనిఖీ క్రాష్ అవ్వడం ఆగిపోయిందని నిర్ధారించి, పబ్లిష్‌ను పాస్ చేసింది.

సెప్టెంబర్ 25న, రెండు యాప్‌లలో ఇది మూడుసార్లు జరిగింది. ప్రతిసారీ:

• పబ్లిష్ లైవ్‌గా గుర్తించబడింది,
• రోల్‌బ్యాక్ నడవలేదు, ఎందుకంటే ఏదీ విఫలం కాలేదు,
• మా రికన్సిలర్, డిప్లాయ్‌మెంట్‌లను ఆ తర్వాత తనిఖీ చేసే ఒక బ్యాక్‌గ్రౌండ్ జాబ్, కొన్ని నిమిషాల తర్వాత డిప్లాయ్‌మెంట్‌ను విఫలం చేసింది,
• మరియు మొత్తం సైట్ 404 ని తిరిగి ఇచ్చింది.

సమయానికి విఫలమయ్యే పబ్లిష్‌ను రోల్‌బ్యాక్ మునుపటి వెర్షన్‌ను తిరిగి పెట్టడం ద్వారా పునరుద్ధరించవచ్చు. విజయంగా ప్రకటించిన తర్వాత కొన్ని నిమిషాల ఆలస్యంగా విఫలమయ్యే పబ్లిష్, అప్పటికే తన రోల్‌బ్యాక్‌ను దాటేసింది.

దీన్ని మేము ఎలా కనుగొన్నాము

మేము దీన్ని స్థానికంగా పునరుత్పత్తి చేశాము: పని చేస్తున్న API ను తీసుకుని, అది నిద్రపోయేలా చేసి, బూట్‌లో క్రాష్ అయ్యే మార్పుతో రీపబ్లిష్ చేశాము. హెల్త్ చెక్ దాన్ని లైవ్ అని గుర్తించింది.

అది ప్రొడక్షన్‌తో సరిపోయింది: ప్రతి మూడు పబ్లిష్‌లలోనూ, యాప్ ప్రతి బూట్‌లోనూ సెకన్ల తర్వాత చనిపోయింది, అయినప్పటికీ తనిఖీ పోల్చిన క్రాష్ లెక్క చూపుల మధ్య ఎప్పుడూ పెరగలేదు.

పరిష్కారం: లెక్కను కాదు, తాజా క్రాష్‌ను పోల్చండి

క్రాష్‌లను లెక్కించే బదులు, తనిఖీ ఇప్పుడు పబ్లిష్ మొదలైనప్పటి నుండి అత్యంత ఇటీవలి క్రాష్ యొక్క సమయాన్ని చూస్తుంది.

రెండవ చూపులో పబ్లిష్ మొదలైనప్పటి నుండి ఏ క్రాష్ చూపినా, తనిఖీ వేచి ఉండి మూడవసారి చూస్తుంది. మూడవ చూపులో తాజా క్రాష్ రెండవ చూపులోని తాజా క్రాష్ కంటే తర్వాత అయితే, మధ్యలో మెషీన్ మళ్లీ క్రాష్ అయింది. అది స్థిరంగా ఉండటం లేదు, మరియు పబ్లిష్ “పబ్లిష్ అయినప్పటి నుండి మెషీన్ పదే పదే క్రాష్ అయింది మరియు ఇంకా రీస్టార్ట్ అవుతోంది” అనే సందేశంతో విఫలమవుతుంది.

ఇది ఈవెంట్ జాబితా ఎంత చిన్నదైనా పనిచేస్తుంది. ఐదు ఈవెంట్‌ల స్లైడింగ్ విండో ఎన్ని క్రాష్‌లు ఉన్నాయో దాచవచ్చు, కానీ ఒక కొత్తది ఇప్పుడే జరిగిందని దాచలేదు — తాజా ఈవెంట్ ఎల్లప్పుడూ ఉంచబడేది.

ఈ మార్పుతో, స్థానిక పునరుత్పత్తి సరిగ్గా ప్రవర్తిస్తుంది: పబ్లిష్ విఫలమవుతుంది, మరియు మునుపటి ఇమేజ్ పునరుద్ధరించబడుతుంది. ప్లాట్‌ఫామ్ ప్రవర్తనను అనుకరించే ఒక టెస్ట్ కూడా ఉంది — ప్రతి చూపు ఒక క్రాష్ మరియు ఒక ప్రారంభం జోడిస్తుంది మరియు జాబితాను ఐదుకు కుదిస్తుంది — తీర్పు విఫలమవడమేనని, పాస్ కాదని తనిఖీ చేస్తుంది.

మేము దీనినుండి నేర్చుకున్నది

• మీరు లెక్కిస్తున్న డేటా ఆకారాన్ని తెలుసుకోండి. పరిమితి ఉన్న జాబితాపై లెక్క, జాబితా నిండిన తర్వాత అర్థం కాదు. ఆ పరిమితి దాగి లేదు; కేవలం మేము దాని చుట్టూ తనిఖీని డిజైన్ చేయలేదు.
• “ఎన్ని జరిగాయి?” కంటే “ఏదైనా కొత్తగా జరిగిందా?” అని అడగండి. ఇటీవలి టైమ్‌స్టాంప్ ట్రంకేషన్ తట్టుకుంటుంది. మొత్తం తట్టుకోదు.
• ఆలస్యమైన విఫలత, ముందు విఫలత కంటే ఘోరం. అదే విరిగిన బిల్డ్ పబ్లిష్ విఫలమై రోల్‌బ్యాక్ అయితే హానికరం కాదు, మరియు ముందు విజయంగా ప్రకటిస్తే సైట్‌ను డౌన్ చేస్తుంది.
• నిజమైన పరిస్థితులతో పునరుత్పత్తి చేయండి. ఈ బగ్‌కు ఈవెంట్ జాబితాను నింపేంత క్రాష్‌లు ఇప్పటికే జరిగిన మెషీన్ కావాలి. టెస్ట్‌లో ఒకే త్వరిత క్రాష్ దీన్ని చూపేది కాదు.

ఈ పరిష్కారం అదే రోజు వచ్చిన మరో దానితో జతచేయబడుతుంది, అది రోల్‌బ్యాక్ తొలగించకుండా పాత వెర్షన్‌ను తిరిగి పెట్టేలా చూసింది: విఫలమైన రీపబ్లిష్ ఎప్పుడూ పనిచేస్తున్న బ్యాకెండ్‌ను తొలగించదు. మీ స్వంత యాప్ బూట్‌లో క్రాష్ కావడం వల్ల పబ్లిష్ కాకపోతే, పబ్లిష్ ట్రబుల్‌షూటింగ్ డాక్స్ మరియు AI తో నిర్మించిన యాప్‌ను డీబగ్ చేయడం పై మా గైడ్ ప్రారంభించడానికి మంచి చోట్లు.