Publish-ஐ இருமுறை அழுத்தினால் இப்போது ஒருமுறை மட்டுமே publish ஆகும்

ஒரே app-க்கான மூன்று publish கோரிக்கைகள் எங்கள் API-ஐ 84 மில்லிவினாடி இடைவெளியில் அடைந்தன; ஒவ்வொன்றும் அந்த app-க்கு ஒரு முழு deploy-ஐத் தொடங்கின. அவை ஒரே hosting-க்குள் ஒன்றோடொன்று போட்டியிட்டன; அவற்றில் பல releases மற்றொன்று முந்திவிட்டதால் தோல்வியடைந்தன. தெரிந்த ஒரே அறிகுறி “release failed” மின்னஞ்சல்தான் — app தானாகவே சரியாக முடிந்தது. இப்போது ஒரே app-க்கு இன்னொரு publish நடந்துகொண்டிருக்கும்போது வரும் publish இரண்டாவது build-ஐத் தொடங்காது. எந்தக் கோரிக்கை வெல்கிறது என்பதை database தீர்மானிக்கிறது; மற்றவற்றுக்கு ஒரு publish ஏற்கனவே இயங்குகிறது என்று உண்மை சொல்லப்படுகிறது.

என்ன நடந்தது

Mythex-இல் ஒரு app-ஐ publish செய்யும்போது, API அதற்கு ஒரு deployment பதிவு செய்கிறது; எங்கள் orchestrator-இடம் — build-ஐ இயக்கும் சேவை — அதை build செய்து வெளியிடக் கேட்கிறது. Publish Publish பொத்தானிலிருந்தோ, மற்றொரு browser tab-இலிருந்தோ, அல்லது நீங்கள் கேட்கும்போது agent-இலிருந்தோ தொடங்கலாம். இரட்டைக் கிளிக், இரண்டு tabs, அல்லது இருமுறை வரும் agent கோரிக்கை எல்லாம் அதே நேரத்தில் ஒரே app-க்கு ஒன்றுக்கு மேற்பட்ட publish-களை உருவாக்கலாம்.

இந்த வழக்கில், மூன்றும் 84 ms-க்குள் வந்தன. ஒவ்வொன்றும் முழு deploy-ஐ இயக்கின. Hosting தளத்தில், அதே app-க்கான releases ஒரே வினாடியில் உருவாக்கப்பட்டன; மற்ற இரண்டும் ஏற்கனவே நடந்துகொண்டிருந்ததால் மூன்றில் மூன்று தோல்வியடைந்தன. பின்னர் ஒரு release ஒட்டிக்கொண்டது, அதன் பின் app வேலை செய்தது.

அதுதான் இதைக் கவனிக்க கடினமாக்கியது. பயனர் ஒரு வேலை செய்யும் app-ஐப் பார்த்தார். தோல்விகள் “release failed” மின்னஞ்சல்களாக மட்டுமே தெரிந்தன.

எதுவும் ஏன் தடுக்கவில்லை

Publish code-இல் ஒரு project-க்கான நடந்துகொண்டிருக்கும் deploys-ஐப் பார்க்கும் ஒரு படி இருந்தது. ஆனால் அது செய்தது, தொடங்குவதற்கு முன் நடந்துகொண்டிருக்கும் ஒவ்வொரு deploy-யையும் தோல்வி எனக் குறிப்பது — “புதிய publish-ஆல் மாற்றப்பட்டது”. அது ஒரு செயலிழந்த செயல்முறை விட்டுச் சென்ற build-களைச் சுத்தம் செய்யவே நோக்கம் கொண்டது.

நடைமுறையில், build நடுவில் வரும் இரண்டாவது publish, முதலாவதை இறந்ததாக அறிவித்து தனக்கென ஒன்றைத் தொடங்கியது. இரண்டும் ஒரே app-க்கு எதிராக முடிந்தன. ஒரு பூட்டும் இல்லை; ஓட்டத்துக்கு வழி உருவாக்குவதில் தீவிரமாகச் செயல்பட்ட ஒரு படி மட்டுமே இருந்தது.

ஒரு app-இன் முதல் publish-இல் இன்னொரு விசித்திரமான அறிகுறியும் இருந்தது. மீண்டும் பயன்படுத்த இன்னும் deployment பதிவு இல்லாததால், ஒரே நேரத்தில் வரும் இரண்டு முதல் publish-களும் ஒன்றைச் செருக முயன்றன. Database-இல் app-இன் link பெயரில் (slug, உதாரணமாக your-app.mythex.ai-இல் your-app) ஒரு unique index உண்டு; இரண்டாவது செருகல் தோல்வியடைந்தது. API அதை “அந்த link பெயர் ஏற்கனவே எடுக்கப்பட்டுள்ளது” என்று மொழிபெயர்த்தது — அந்த நேரத்தில் அதே பெயரில் வெற்றிகரமாக publish ஆகிக்கொண்டிருந்த app-ஐ பெயர் மாற்றச் சொன்னது.

தீர்வு: உரிமைகோரல்தான் பூட்டு

Deployment பதிவை உரிமை கோருவது இப்போது ஒரே நிபந்தனைக்குட்பட்ட database update: இந்த வரிசையை எடுத்து, யாரும் அதை publish செய்யவில்லை என்றால் மட்டும் அதை building எனக் குறி. அது ஒரே statement என்பதால், ஒரே மில்லிவினாடியில் வரும் கோரிக்கைகளை database தீர்த்து வைக்கிறது. சரியாக ஒன்றுதான் வரிசையை மாற்றுகிறது. மற்றவை மாற்றம் பூஜ்யம் என்று பார்த்து நின்றுவிடுகின்றன; orchestrator-ஐ ஒருபோதும் அடைவதில்லை.

ஒரு பூட்டுக்கு அதன் உரிமையாளர் இறக்கும்போது வெளியேற ஒரு வழியும் தேவை. Publish நடுவில் API மறுதொடங்கினால், வரிசை எப்போதும் “building” எனக் குறிக்கப்பட்டு app-ஐ publish செய்ய முடியாமல் போகும். ஆகவே heartbeats அனுப்பாத வரிசையை — நடக்கும் publish ஒவ்வொரு 30 வினாடிக்கும் வரிசையைப் புதுப்பிக்கிறது, ஐந்து நிமிட மௌனம் இறந்ததாகக் கருதப்படுகிறது — மீண்டும் உரிமை கோரலாம். அந்த வரம்பு heartbeat-இலிருந்து வருகிறது, build எவ்வளவு நேரம் எடுக்கும் என்ற ஊகத்திலிருந்து அல்ல. பயனரின் சொந்த Dockerfile-ஐ build செய்வது நியாயமாக நீண்ட நேரம் எடுக்கலாம்; heartbeat அனுப்பிக்கொண்டிருக்கும் மெதுவான build அதன் உரிமையைத் தக்கவைக்கும்.

Publish தொடங்கும் முன் நடந்துகொண்டிருந்த எல்லா deploys-ஐயும் தோல்வி எனக் குறித்த படி இனி ஓடாது. இறந்த செயல்முறைகள் விட்டுச் சென்ற வரிசைகள் மட்டுமே சுத்தம் செய்யப்படுகின்றன.

தோற்றவருக்கு உண்மையைச் சொல்வது

தோற்ற கோரிக்கைக்கு இப்போது தெளிவான பதில் கிடைக்கிறது: publish_in_progress, இயங்கிக்கொண்டிருக்கும் deployment-இன் ID உடன். Publish தொடங்கக்கூடிய ஒவ்வொரு இடமும் அதைக் கையாள்கிறது:

• Workspace ஏற்கனவே இயங்கும் build-ஐப் பின்தொடர்கிறது; அதன் மேல் பிழையைக் காட்டுவதில்லை.
• Agent-க்கு அந்த app-இன் publish ஏற்கனவே இயங்குகிறது என்றும், அதற்காகக் காத்திருக்கவும் சொல்லப்படுகிறது; ஏதோ தோல்வியடைந்தது என்று சொல்லப்படுவதில்லை. முன்பு அது Dockerfile-ஐ “சரிசெய்து” மீண்டும் முயல அனுப்பப்படலாம்.
• முதல்-publish மோதல் link பெயரில் சரிபார்க்கப்படுகிறது: பெயரைப் பிடித்திருக்கும் வரிசை இந்தத் project-இன் சொந்த இயங்கும் publish என்றால், பதில் “ஏற்கனவே publish ஆகிக்கொண்டிருக்கிறது”, “அந்தப் பெயர் எடுக்கப்பட்டுள்ளது” அல்ல. வேறு project-உடனான உண்மையான மோதல் இன்னும் பெயர் மாற்றச் செய்தியைப் பெறும்.

இதை எப்படிச் சரிபார்த்தோம்

உண்மையான database மற்றும் போலியான orchestrator எதிராக ஒரே app-இன் மூன்று publish-களை ஒரே நேரத்தில் இயக்கும் மறு-உருவாக்கல் ஸ்கிரிப்டை எழுதினோம்; orchestrator எத்தனை deploys கேட்கப்படுகிறது என்று எண்ணுகிறது. அது முதல் publish மற்றும் வாழும் app-இன் மறு-publish இரண்டையும் உள்ளடக்குகிறது. சரிசெய்வதற்கு முன் இரண்டு deploys எண்ணப்பட்டன. பின்னர் ஒன்று.

ஸ்கிரிப்ட் தப்பிக்கும் வழியையும் உள்ளடக்குகிறது: app-இன் வரிசையை பத்து நிமிடங்களுக்கு heartbeat இல்லாமல் building எனக் குறிக்கிறது, மீண்டும் publish செய்கிறது, புதிய publish வரிசையை உரிமை கோரி இயங்குகிறதா என்று சரிபார்க்கிறது.

அலகுச் சோதனைகள் பூட்டை அது செய்ய வேண்டிய இரண்டு விஷயங்களுக்கு வைத்திருக்கின்றன: ஒரே நேரத்தில் வரும் மூன்று மறு-publish-களில் சரியாக ஒன்றுதான் உள்ளே செல்லும், மற்ற இரண்டுக்கும் ஒரு publish இயங்குகிறது என்று சொல்லப்படும்; உரிமையாளர் இறந்த build-ஐ உரிமை கோரலாம். மற்றொரு சோதனை, புதிய முயற்சி முந்தைய முயற்சியின் பிழைச் செய்தியைச் சுமந்து செல்லவில்லை என்பதைச் சரிபார்க்கிறது.

நாங்கள் கற்றது

• சுத்தம் செய்யும் code ஒரு போட்டியாக மறைந்திருக்கலாம். “நடப்பதை எல்லாம் தோல்வி எனக் குறி, பின்னர் தொடங்கு” என்பது சுகாதாரமாகத் தோன்றும். இரண்டு அழைப்பாளர்கள் இருந்தால், அது ஒவ்வொருவரும் மற்றவரை ரத்து செய்வது.
• Database தீர்ப்பளிக்கட்டும். ஒரு படிப்பும் அதைத் தொடர்ந்து ஒரு எழுத்தும் மற்றொரு கோரிக்கைக்கு இடைவெளி விடுகின்றன. ஒற்றை நிபந்தனைப் update விடுவதில்லை.
• ஒவ்வொரு பூட்டுக்கும் உயிர்ப்பு-உடன் இணைந்த ஒரு காலாவதி தேவை. இல்லாவிட்டால், ஒரு செயலிழப்பு ஒட்டிக்கொண்ட app ஆகிவிடும்.
• பிழைச் செய்திகள் அறிவுறுத்தல்கள். “அந்தப் பெயர் எடுக்கப்பட்டுள்ளது” என்றது மக்களைத் தவறான செயலுக்குத் தூண்டியது. சரியான செய்தி எளிமையானதும் உண்மையானதுமாக இருந்தது.

Publishing பற்றி docs-இல்: how to publish. தொடர்புடைய ஒரு சரிசெய்தல்: மீண்டும் publish செய்யும்போதும் உங்கள் வெளியிடப்பட்ட app உயிருடன் இருக்கும்.