Phase 13: Tools & Protocols

एमसीपी विश्वसनीयता, रद्द करना और प्रवाह नियंत्रण

एक अनुरोध आईडी संदेश से जुड़ी होती है। यह किसी दुष्प्रभाव को सुरक्षित नहीं बनाता है, एक कार्यकर्ता को रोकता है, या धीमी उपभोक्ता से धारा की रक्षा नहीं करता है।

Type: Build

Languages: Python

Prerequisites: Phase 13, Lessons 09 and 13

Time: ~120 minutes

सीखने के लक्ष्य

stdio और Streamable HTTP के लिए सही रद्द सिग्नल लागू करें।
रद्द होने के बाद संदेश भेजने के बिना समाप्ति और रद्द दौड़ का समाधान करें।
स्थायी से अलग अनुरोध रद्द करना tasks/cancelअर्थशास्त्र।
दुष्प्रभावों और स्पष्ट असमर्थता कुंजी से पुनः प्रयास निर्णय बनाएं।
अंतिम प्रतिक्रियाओं को संरक्षित करते हुए प्रगति की कतारों को सीमित करें।
पुनः कनेक्ट, रिफैच, और झटका बैकऑफ के माध्यम से धाराओं को पुनर्प्राप्त करें।

समस्या

खुश पथ सबसे महंगी वितरित प्रणाली कीड़े छिपाता है।

एक क्लाइंट एक उपकरण को कॉल करता है। सर्वर काम शुरू करता है। प्रगति आती है। एक प्रॉक्सी स्ट्रीम को बफर करता है। क्लाइंट अपना टाइमआउट तक पहुंचता है और डिस्कनेक्ट होता है। सर्वर एक मिलीसेकंड बाद समाप्त होता है। क्लाइंट एक नई JSON-RPC आईडी के साथ पुनः प्रयास करता है। उत्परिवर्तन दो बार चलता है।

प्रत्येक घटक स्थानीय रूप से व्यवहार किया। प्रणाली वैश्विक रूप से विफल रही।

MCP संदेश और परिवहन व्यवहार को परिभाषित करता है, लेकिन आपके आवेदन अभी भी हैः

समय के बजट;
व्यापारिक असमर्थता;
सीमांत कतारें;
पुनः प्रयास वर्गीकरण;
टिकाऊ कार्य स्थिति;
नीति को फिर से जोड़ें और फिर से संशोधित करें।

यह सबक उन निर्णयों को एक निर्धारक सिम्युलेटर में बनाता है।

कोई सोप, सॉकेट, या यादृच्छिक विफलता नहीं है. आप रद्द घटना आदेश नियंत्रित

एक सिंक्रनाइज़्ड थ्रेड परीक्षण दो लेजर क्लाइंट्स को प्रतिस्पर्धा करने के लिए मजबूर करता है

उसी असमर्थता कुंजी के लिए।

रद्द करने की मांग परिवहन के लिए विशिष्ट है

हर परिवहन पर इरादा एक ही हैः ग्राहक को उड़ान के दौरान परिणाम की आवश्यकता नहीं है। तार सिग्नल अलग है।

स्टूडियो

stdio एक साझा द्वि-दिशात्मक चैनल का उपयोग करता है। एक क्लाइंट एक सूचना भेजता हैः

json{
  "jsonrpc": "2.0",
  "method": "notifications/cancelled",
  "params": {
    "requestId": 41,
    "reason": "User closed the operation"
  }
}

सूचना आग और भूल है. सर्वर कोई JSON-RPC प्रतिक्रिया नहीं भेजता है.

सर्वर को काम करना बंद करना चाहिए, संसाधनों को मुक्त करना चाहिए, और रद्द किए गए अनुरोध के लिए प्रतिक्रिया भेजने से बचना चाहिए। यह रद्द करने की अनदेखी कर सकता है जब अनुरोध अज्ञात है, पहले से ही समाप्त हो गया है, या सुरक्षित रूप से रोक नहीं सकता है।

गलत रूप से तैयार, अज्ञात और पहले से ही पूरा रद्द सूचनाओं को अनदेखा किया जाता है। उन दौड़ों को नई त्रुटियों में बदलना अधिक दौड़ पैदा करेगा।

स्ट्रीम करने योग्य HTTP

आधुनिक स्ट्रीम करने योग्य HTTP प्रत्येक अनुरोध को अपनी HTTP प्रतिक्रिया या SSE प्रतिक्रिया धारा देता है। क्लाइंट उस अनुरोध की प्रतिक्रिया धारा को बंद करके रद्द करता है।

पोस्ट न करें notifications/cancelledएक साधारण HTTP अनुरोध के लिए. धारा बंद करने के लिए रद्द करने के संकेत है.

सर्वर ने डिस्कनेक्ट को देखने के बाद, उसे काम करना बंद कर देना चाहिए और उस अनुरोध के लिए और संदेश नहीं भेजना चाहिए।

सर्वर द्वारा भेजे जाने वाले रद्द करना संकीर्ण है

सर्वर उपयोग नहीं करता है notifications/cancelledस्टूडियो पर, सर्वर द्वारा भेजे गए रद्द करने के लिए एक समाप्त करने के लिए आरक्षित हैsubscriptions/listenअनुरोध. उस पथ को सामान्य ग्राहक अनुरोध रद्द से अलग रखें.

रद्द करना एक दौड़ है

दो घटना आदेश दोनों मान्य हैं।

रद्द करने की जीत

textrequest starts
client sends cancellation signal
server marks request cancelled
worker reaches completion
server suppresses the response

पूरा होने की जीत

textrequest starts
worker commits the result
server sends the response
cancellation arrives late
server ignores the late notification

ग्राहक को पहले ही छोड़ दिया गया अनुरोध के लिए देर से प्रतिक्रिया को भी अनदेखा करना चाहिए। नेटवर्क विलंबता का मतलब है कि कोई भी पक्ष यह साबित नहीं कर सकता है कि दूसरे पक्ष ने पहले किस घटना का निरीक्षण किया।

सबक RequestCoordinatorएक टर्मिनल राज्य को स्टोर करता है। complete()रद्द करने के बाद कोई प्रतिक्रिया नहीं देता है। देर से रद्द करने से पूर्ण रिकॉर्ड नहीं बदल सकता है।

समय सीमा दो घड़ियों की आवश्यकता होती है

एक ही निष्क्रियता टाइमर पर्याप्त नहीं है।

दो सीमाओं का प्रयोग करेंः

Idle timeout.अनुरोध से कोई उपयोगी गतिविधि नहीं हो सकती।
Maximum timeout.अनुरोध शुरू से पूर्ण दीवार घड़ी बजट.

प्रगति से निष्क्रिय घड़ी को रीसेट किया जा सकता है।

textstart: 0 ms
progress: 400 ms
progress: 800 ms
progress: 1200 ms
idle timeout: 500 ms
maximum timeout: 2000 ms

1500 ms पर, अनुरोध अभी भी सक्रिय है क्योंकि नवीनतम प्रगति केवल 300 ms पुरानी है। 2000 ms पर, अधिकतम समय सीमा इसे रद्द करती है भले ही 1999 ms पर एक और प्रगति घटना आई हो।

प्रगति वैकल्पिक है. एक सर्वर प्रगति टोकन को स्वीकार कर सकता है और कोई अपडेट जारी नहीं कर सकता है. कभी भी टोकन की उपस्थिति को अंतहीन टाइमआउट में न बदलें।

एमसीपी प्रगति मानों में वृद्धि होनी चाहिए। अधिसूचनाएं समाप्त होने या रद्द होने के बाद रुक जाती हैं। दर सीमा प्रगति ताकि एक तेज कार्यकर्ता परिवहन को बाढ़ से नहीं भर सके।

रद्द करने की मांग नहीं है `tasks/cancel`

ये तंत्र विभिन्न जीवनकाल को हल करते हैं।

Mechanism	Target	Signal	What success means
Request cancellation on stdio	One in-flight RPC	`notifications/cancelled`	Client abandoned the request; server should stop if practical
Request cancellation on HTTP	One in-flight response stream	Close the stream	Client abandoned the request; server should stop if practical
`tasks/cancel`	One durable Task	Ordinary MCP request	Server acknowledged cancellation intent

एक सफल tasks/cancelपरिणाम यह साबित नहीं करता है कि श्रमिक रुक गया है। कार्य रह सकता है workingजब तक कि एक कर्मचारी चेकपोस्ट ध्वज का निरीक्षण नहीं करता।

HTTP कनेक्शन बंद होने पर टिकाऊ कार्य स्थिति को न हटाएं। एक कार्य बनाने का कारण यह है कि इसका जीवन चक्र एक अनुरोध और एक कनेक्शन से अधिक रहता है।

एक नई JSON-RPC आईडी एक असंगतता नहीं है

JSON-RPC ids अनुरोधों और प्रतिक्रियाओं को संबद्ध करते हैं। वे एक व्यावसायिक संचालन की पहचान नहीं करते हैं।

मान लीजिए कि एक ग्राहक आईडी के साथ एक शुल्क जमा करता है 41, प्रतिक्रिया खो देता है, और आईडी के साथ पुनः प्रयास करता है42सर्वर दो अलग-अलग संदेश देखता है। आवेदन कुंजी के बिना, यह नहीं पता है कि वे एक चेकआउट प्रतिनिधित्व करते हैं.

एक idempotency कुंजी व्यवसायिक इरादे की पहचान करती हैः

json{
  "name": "charge_account",
  "arguments": {
    "account": "acct-7",
    "cents": 1200,
    "idempotencyKey": "checkout-7"
  }
}

सर्वर स्टोरः

कुंजी;
ऑपरेशन तर्क का एक फिंगरप्रिंट;
प्रतिबद्ध परिणाम।

एक ही कुंजी और एक ही तर्क संग्रहीत परिणाम को वापस करते हैं। एक ही कुंजी विभिन्न तर्क के साथ खारिज कर दिया जाता है। यह एक अलग व्यावसायिक संचालन में उत्परिवर्तन से गलती से कुंजी के पुनः उपयोग को रोकता है।

लेजर की सीमा परमाणु और टिकाऊ होनी चाहिए

यह अनुक्रम असुरक्षित हैः

textcheck key
run mutation
store result

दो श्रमिक दोनों एक गायब कुंजी का निरीक्षण कर सकते हैं और दोनों उत्परिवर्तन चला सकते हैं।

प्रभाव के बाद लेकिन दुकान से पहले एक ही अस्पष्टता पुनः प्रयास पर बनाता है।

पाठ एक फ़ाइल-समर्थित SQLite लेजर का उपयोग करता है। BEGIN IMMEDIATEक्रमबद्ध करता है

कुंजी जांच, अनुकरण व्यापार प्रभाव, निष्पादन काउंटर, और संग्रहीत परिणाम में

एक लेनदेन दो स्वतंत्र लेजर कनेक्शन एक ही कुंजी के साथ दौड़

इसलिए एक प्रतिबद्ध परिणाम और एक निष्पादन का पालन करें।

पुस्तक उस रिकॉर्ड को रखता है।

प्रत्येक रिटर्न मान संग्रहीत JSON से पुनर्निर्माण किया जाता है. कॉल करने वाला कभी नहीं प्राप्त करता है

लेजर में रखे गए परिवर्तनीय वस्तु, इसलिए लौटाए गए शब्दकोश को बदलना संभव नहीं है

भ्रष्ट बाद में पुनः खेल परिणाम.

सिम्युलेटर का व्यापार प्रभाव रिसीव और निष्पादन काउंटर के अंदर है

एक वास्तविक भुगतान, तैनाती, या बाहरी एपीआई कॉल है

उत्पादन को एक स्थायी और स्थिर

साझा डेटाबेस लेनदेन, लेनदेन आउटबॉक्स या अपस्ट्रीम प्रदाता

एक प्रक्रिया लॉक अकेले सुरक्षा नहीं करता है

कई प्रतिकृति या एक पुनरारंभ से बचने के लिए।

पुनः परीक्षण मैट्रिक्स

उन्हें लागू करने से पहले पुनः प्रयासों को वर्गीकृत करें।

Class	Example	Retry rule
Safe	Deterministic read with no side effect	Retry with a new JSON-RPC id after the failure boundary is understood
Conditional	Mutation with a durable idempotency key	Retry with the same key and identical arguments
Unsafe	Mutation without business deduplication	Do not retry automatically; reconcile first

उपकरण के रूप में टिप्पणी readOnlyHintऔर idempotentHintअनुप्रयोग अनुबंध और सर्वर कार्यान्वयन सुरक्षा पुनः प्रयास करने का निर्णय लेते हैं।

दबाव सही है

एक एसएसई निर्माता क्लाइंट, प्रॉक्सी या नेटवर्क से अधिक तेजी से प्रगति उत्पन्न कर सकता है। एक असीमित कतार धीमी गति को स्मृति थकावट में परिवर्तित करती है।

एक सीमित कतार का उपयोग करें और परिभाषित करें कि क्या खोया जा सकता है।

प्रगति प्रतिस्थापन योग्य है। एक बाद में प्रगति मूल्य एक ही टोकन के लिए एक पहले के प्रतिस्थापन करता है। अंतिम JSON-RPC प्रतिक्रिया प्रतिस्थापन योग्य नहीं है।

पाठ बफर इस नीति को लागू करता हैः

इसी के लिए आसन्न प्रगति को संरेखित करें।
क्षमता तक पहुंचने पर सबसे पुरानी प्रगति को छोड़ दें।
धारा को अधिकृत रीफेश की आवश्यकता के रूप में चिह्नित करें।
अंतिम प्रतिक्रिया को बनाए रखें।
एक ऐसी स्थिति से इनकार करें जहां अंतिम प्रतिक्रिया को संरक्षित करने के लिए एक और अंतिम प्रतिक्रिया को छोड़ना आवश्यक हो।

यह स्पष्ट वसूली के साथ सीमित हानि है. चुपके नुकसान एक रणनीति नहीं है.

प्रॉक्सी बफरिंग

एक सर्वर सही ढंग से स्ट्रीम कर सकता है जबकि एक रिवर्स प्रॉक्सी बफर में घटनाओं को रखता है।

SSE प्रतिक्रिया के लिए, भेजेंः

httpContent-Type: text/event-stream
Cache-Control: no-cache
X-Accel-Buffering: no

2026 स्ट्रीम करने योग्य HTTP विनिर्देश अनुशंसा करता है X-Accel-Buffering: noइसलिए संगत प्रॉक्सी तुरंत घटनाओं को वितरित करते हैं।

शांत लंबे समय तक चलने वाली धाराओं के लिए, आवधिक रूप से एक एसएसई टिप्पणी जारी करेंः

text:

ग्राहक टिप्पणी लाइनों को अनदेखा करता है मध्यस्थ ट्रैफ़िक देखते हैं और निष्क्रिय कनेक्शन को बंद करने की संभावना कम होती है।

एक ऑपरेशन के अर्थिक निष्क्रिय समय सीमा को बस इसलिए रीसेट न करें क्योंकि एक परिवहन टिप्पणी आई है।

पुनः जोड़ने का अर्थ है पुनः प्राप्त करना

आधुनिक स्ट्रीम करने योग्य HTTP पुनः आरंभ करने योग्य SSE का समर्थन नहीं करता है Last-Event-ID. .

एक के बाद subscriptions/listenधारा की बूंदेंः

एक नई JSON-RPC आईडी के साथ एक नया सुन अनुरोध खोलें।
वांछित सदस्यता फ़िल्टर को पुनर्स्थापित करें।
प्रामाणिक तरीकों से प्रभावित उपकरण, संसाधन, संकेत या कार्यों को पुनः प्राप्त करें।
स्थिर पहचानकर्ताओं द्वारा आवेदन स्थिति को दोहराएं।
एक असुरक्षित उत्परिवर्तन को सिर्फ इसलिए न दोहराएं क्योंकि इसकी प्रतिक्रिया खो गई थी।

नमूना वसूली योजना में स्पष्ट रूप से निर्धारित किया गया है sendLastEventIdझूठी और पुनरावृत्ति के लिए संसाधनों की सूची।

एक पुनर्मिलन झुंड को रोकें

यदि 10,000 क्लाइंट एक सेकंड में फिर से कनेक्ट होते हैं, तो पुनर्प्राप्त करने वाला सर्वर फिर से विफल हो जाता है।

एक टॉप और एक जिएटर के साथ एक्सपोनेंशियल बैकऑफ का उपयोग करें। पाठ क्लाइंट आईडी और प्रयास संख्या से निर्धारात्मक जिएटर की गणना करता है ताकि परीक्षण पुनः उत्पन्न हो सकेंः

textattempt 0: up to 250 ms
attempt 1: up to 500 ms
attempt 2: up to 1000 ms
...
cap: 8000 ms

उत्पादन क्रिप्टोग्राफिक रूप से सुरक्षित या रनटाइम रैंडमनेस का उपयोग कर सकता है। अपरिवर्तनीय वितरण है, एक विशिष्ट सूत्र नहीं।

इसे बनाओ

code/main.pyपांच छोटे विश्वसनीयता घटकों का निर्माण करता है।

`RequestCoordinator`

उड़ान में निष्क्रिय और अधिकतम समय सीमा के साथ एक अनुरोध शुरू करता है;
प्रगति की एकतरफा सूचनाएं जारी करता है;
सही स्टूडियो या HTTP रद्द सिग्नल उत्पन्न करता है;
अमान्य रद्द सूचनाओं को अनदेखा करता है;
रद्द करने और समाप्त करने की अंतिम दौड़ को स्पष्ट करता है;
स्टूडियो सदस्यता के लिए सर्वर द्वारा भेजे गए रद्द करने के लिए आरक्षित।

`MutationLedger`

यह साबित करता है कि दो JSON-RPC आईडी दो बार निष्पादित होती हैं बिना व्यवसाय कुंजी के;
कुंजी जांच, अनुकरण प्रभाव के लिए फ़ाइल-समर्थित SQLite लेनदेन का उपयोग करता है,

निष्पादन काउंटर और परिणाम प्रतिबद्धता;

स्वतंत्र पार एक idempotency कुंजी के तहत मेल खाने वाले तर्क को दोहराता है

लेजर कनेक्शन;

एक कुंजी को अलग-अलग तर्क के साथ पुनः उपयोग करने से इनकार करता है;
रक्षा प्रतियां वापस करती है और फिर से खोलने के दौरान प्रतिबद्ध रिकॉर्ड को संरक्षित करती है।

`DurableTaskService`

रद्द करने के अनुरोध को स्वीकार करता है;
कार्य को बनाए रखता है workingएक श्रमिक नियंत्रण कक्ष तक;
यह दर्शाता है कि मान्यता अंतिम स्थिति क्यों नहीं है।

`BoundedSseBuffer`

दबाव में प्रगति को संयुग्मित या घटाता है;
रिकॉर्ड कि अधिकृत पुनर्स्थापना की आवश्यकता है;
कभी भी अंतिम प्रतिक्रिया नहीं छोड़ता है।

पुनर्वास सहायता

प्रोक्सी-सुरक्षित SSE हेडर और रखरखाव संबंधी टिप्पणियां लौटाएं;
एक पुनः कनेक्ट और रिफ्रेश प्लान बनाएं;
निर्धारात्मक घातीय बैकऑफ और जिक्र के साथ प्रसार पुनः प्रयास।

इसका प्रयोग करें

भंडारण मूल सेः

bashcd phases/13-tools-and-protocols/29-mcp-reliability-cancellation-and-flow-control/code
python3 main.py
python3 -m unittest discover tests -v

डेमो मध्य दौड़ के दोनों पक्षों चलाता है, लेनदेन के रूप में एक निष्पादित

अस्थायी फ़ाइल-समर्थित लेजर में डिडप्लिकेट उत्परिवर्तन, एक सीमाबद्ध

प्रगति बफर, और एक स्थायी कार्य को दर्शाता है स्वीकार रद्द करने से आगे बढ़ रहा है

श्रमिकों द्वारा देखी जाने वाली रद्द करने के लिए।

इंटरैक्टिव लैब

नींद जोड़ने के बिना चार घटनाओं के आदेश चलाएं।

अनुरोध शुरू करें A, इसे रद्द, फिर कॉल complete(). .
अनुरोध शुरू करें B, इसे पूरा, और फिर रद्द करने की आपूर्ति.
अनुरोध शुरू करें C, हर निष्क्रिय समय सीमा से पहले प्रगति जारी करें, फिर अधिकतम समय सीमा पार करें।
अनुरोध शुरू करें Dपर स्ट्रीम करने योग्य HTTP और अपनी प्रतिक्रिया धारा बंद.

प्रत्येक परिदृश्य के लिए रिकॉर्डः

टर्मिनल अनुरोध की स्थिति;
क्या कोई अंतिम प्रतिक्रिया मौजूद है;
तार पर रखा गया रद्द सिग्नल;
ग्राहक को किस घटना को नजरअंदाज करना चाहिए।

तो बदल Dऑपरेशन समान है, लेकिन रद्द करने के संकेत बदलना होगा.

अभ्यास प्रयोगशाला

एक जोड़ें reserve_inventory में उत्परिवर्तनMutationLedger. .

आवश्यकताएँः

कुंजी SKU, मात्रा, किरायेदार और संचालन नाम को बाध्य करती है।
एक ही कुंजी और एक ही तर्क के साथ पुनः प्रयास करने से पहला आरक्षण वापस आ जाता है।
एक संशोधित मात्रा के साथ पुनः प्रयास एक और आरक्षण के बिना विफल रहता है।
एक निष्पादन जो किया गया था लेकिन अपनी प्रतिक्रिया खो दिया है, कुंजी द्वारा मेल खाया जा सकता है।
परिणाम में कोई गुप्त या भुगतान डेटा दर्ज नहीं किया गया है।
यदि ग्राहक ने कुंजी प्रदान नहीं की है तो स्वचालित पुनः प्रयास निष्क्रिय कर दिया जाता है।
आगे क्या करना है, यह तय करने से पहले अनुबंध ड्रॉप का अनुकरण करें और इन्वेंट्री रिकॉर्ड को फिर से जोड़ें।
एक बाधा पर दो लेजर कनेक्शन शुरू करें और एक ही कुंजी प्रस्तुत करें

एक आरक्षण किया गया था।

पहले लौटा आरक्षण वस्तु को उत्परिवर्तन करें. कुंजी फिर से खेलें और साबित करें कि

संग्रहीत परिणाम में कोई परिवर्तन नहीं हुआ।

लॉजर फ़ाइल को बंद और फिर से खोलें, फिर कुंजी द्वारा आरक्षण को मिलाएं।

प्रयोगशाला को ईमानदार रखेंः यदि इन्वेंट्री किसी अन्य सेवा में रहती है, तो समझाएं कि क्या

यह सेवा उसी idempotency key को स्वीकार करती है या क्या एक transactional outbox

पुल स्थानीय दूरस्थ प्रभाव के लिए प्रतिबद्ध.

शिप की गई कलाकृतियाँ

outputs/skill-mcp-reliability-reviewer.mdयह एक MCP ऑपरेशन, परिवहन, टाइमआउट नीति, पुनः प्रयास व्यवहार, कतार नीति और वसूली योजना देता है। यह एक दौड़ तालिका, पुनः प्रयास वर्गीकरण, असमर्थता सीमा, प्रवाह नियंत्रण जांच और विफलता फिक्स्चर देता है।

जाँचें

जब ये कथन सच होते हैं तो पाठ पूरा हो जाता हैः

स्टूडियो रद्द भेजता है notifications/cancelledऔर कोई प्रतिक्रिया नहीं मिलती है।
स्ट्रीम करने योग्य HTTP रद्द अनुरोध धारा को बंद करता है और कोई रद्द POST नहीं भेजता है।
समाप्त होने से पहले रद्द करना अंतिम प्रतिक्रिया को दबा देता है।
पूर्ण पूर्व-बदला प्रतिक्रिया को संरक्षित करता है और देर से रद्द करने की अनदेखी करता है।
प्रगति निष्क्रिय समय को रीसेट कर सकती है लेकिन अधिकतम समय कभी नहीं।
एक नया JSON-RPC आईडी अकेले उत्परिवर्तन फिर से निष्पादित करता है।
एक idempotency कुंजी और समान तर्क एक समवर्ती के तहत एक बार निष्पादित

दो कनेक्शन दौड़.

एक प्रतिबद्ध रिकॉर्ड फिर से खोलने से बचता है और पुनरावृत्ति एक रक्षात्मक प्रतिलिपि देता है।
एक लौटाए गए परिणाम को म्यूट करने से संग्रहीत परिणाम नहीं बदल सकता है।
सीमाबद्ध बफर क्षमता के भीतर रहता है और अंतिम प्रतिक्रिया को संरक्षित करता है।
रीकनेक्ट एक नया अनुरोध का उपयोग करता है, भेजता नहीं है Last-Event-ID, और प्रभावित राज्य को फिर से बदलता है।
tasks/cancelमान्यता कार्य को कर्मियों द्वारा पालन किए जाने तक अस्थायी छोड़ देती है।

उत्पादन विफलता मोड

Failure	Observable symptom	Correct response
HTTP client POSTs cancellation notification	Server and client disagree about request lifetime	Close the request's SSE response stream
Server responds after accepted cancellation	Client receives an unusable late result	Stop work and suppress further messages when cancellation wins
Progress resets every deadline	Hung work survives forever	Keep a separate absolute maximum timeout
New RPC id treated as deduplication	Charge, deployment, or deletion runs twice	Add a durable application idempotency key
Key check and effect are separate	Concurrent workers both observe a missing key	Commit key claim, effect record, and result atomically
In-memory ledger used across replicas	Restart or another worker forgets prior commits	Use shared durable storage or upstream idempotency
Stored mutable result returned directly	Caller mutation corrupts later replays	Serialize committed results and return defensive copies
Key reused with changed arguments	One key aliases two business intents	Store and compare an argument fingerprint
Unbounded progress queue	Memory rises with a slow consumer	Coalesce and drop replaceable progress within a bound
Final response dropped under pressure	Client cannot know the request outcome	Reserve capacity or evict progress, never the final response
Proxy buffers SSE	Progress arrives in bursts or after timeout	Disable buffering and configure compatible proxy timeouts
`Last-Event-ID` assumed	Client resumes from state the server does not support	Reconnect with a new request and refetch
Every client reconnects immediately	Recovery creates another outage	Use capped exponential backoff with jitter
Task ack treated as final cancellation	Worker keeps running after UI says stopped	Poll the Task until a terminal status

कैपस्टोन कनेक्शन

उपकरण-इकोसिस्टम की अंतिम पत्थर को विश्वसनीयता को निष्पादन योग्य सबूत के रूप में माना जाना चाहिए, वास्तुकला आरेख में एक पैराग्राफ नहीं।

इन कलाकृतियों की आवश्यकता हैः

प्रत्येक परिवहन के लिए एक रद्द दौड़ प्रतिलिपि;
प्रत्येक प्रकट उत्परिवर्तन के लिए एक पुनः परीक्षण तालिका;
एक असंगतता कुंजी रिकॉर्ड और असंगतता फिक्स्चर;
एक समवर्ती समान कुंजी प्रतिलिपि, एक पुनः खोलने की जांच और एक उत्परिवर्तन-अज्ञात जांच;
एक सीमित बफर अधिभार परिणाम;
रिवर्स प्रॉक्सी एसएसई हेडर और निष्क्रिय नीति;
एक पुनर्मिलन योजना जिसमें प्रामाणिक पुनर्मिलन विधियों का नाम दिया गया है;
जब टॉपस्टोन का उपयोग करता है तो एक टिकाऊ टास्क रद्द करने का निशान।

स्थानीय प्रक्रिया में एक हरे रंग का अनुरोध केवल खुश पथ साबित करता है। जब प्रतिक्रियाएं खो जाती हैं, देर से रद्द, धीमी उपभोक्ता और झुंडों को फिर से जोड़ने के परिणाम निर्धारक होते हैं तो टॉपस्टोन उत्पादन के लिए तैयार होता है।

प्रमुख शर्तें

Term	Meaning
Request cancellation	Abandonment of one in-flight MCP request
Cancellation race	Competition between terminal completion and cancellation events
Idle timeout	Limit since the last useful request activity
Maximum timeout	Absolute limit from request start, unaffected by progress
Idempotency key	Application identifier that deduplicates one business intent
Atomic ledger	Durable boundary that commits the key claim, effect record, and result as one unit
Backpressure	Control applied when producers outpace consumers
Progress coalescing	Replacing older progress with a newer authoritative value
Refetch	Reading current state again after a stream gap
Jitter	Deliberate variation that spreads retries across time

आगे पढ़ना

This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.

Browse the complete course catalog or open this lesson on GitHub.