AI agent retry logging duplicate effects को सामने लाने के लिए

Agent retry किसी action की दूसरी copy नहीं होता। यह एक घोषित action पूरा करने की दूसरी कोशिश होती है, और audit trail को यह अंतर सुरक्षित रखना चाहिए। अगर आपके records में केवल मिलती-जुलती HTTP calls की श्रृंखला दिखती है, तो आपने recovery और repetition को एक जैसा बना दिया है।

यह अंतर सबसे ज़्यादा तब मायने रखता है जब action दुनिया में कोई बदलाव करता है: ticket बनाना, access रद्द करना, payment post करना, deployment push करना या SSH पर command चलाना। Destination के action लेने के बाद agent को timeout मिल सकता है। यह भी हो सकता है कि machine से कोई byte बाहर जाने से पहले local failure हो जाए और agent फिर कोशिश करे। इन दोनों स्थितियों पर अलग प्रतिक्रिया चाहिए, फिर भी बहुत-से systems दोनों को request failed, retrying लिखते हैं।

मैंने teams को alleged duplicate actions की जाँच timestamps और payloads को हाथ से मिलाकर करते देखा है। यह event model का खराब विकल्प है। Action होने के समय ही हर record में यह संबंध दर्ज करें। Investigator को operation चुनकर उसका intent, हर attempt, बाद की हर कोशिश का कारण और अंततः तय हुआ outcome दिख जाना चाहिए।

Retry log line का नहीं, operation का हिस्सा होता है

हर side-effecting agent action को दो identities चाहिए: intended result के लिए operation ID और एक execution try के लिए attempt ID। Operation ID उस क्षण से बनी रहती है जब agent तय करता है कि वह क्या करना चाहता है, और तब तक रहती है जब तक आप उस intent को close या reconcile न कर दें। हर network call या SSH execution को नया attempt ID मिलता है।

मान लीजिए agent किसी account को disable करना चाहता है। वह operation op_7f2c बनाता है। पहली request, att_01, identity API तक पहुँचती है, लेकिन response आने से पहले connection बंद हो जाता है। दूसरी request, att_02, उचित recovery attempt हो सकती है। दोनों records को op_7f2c की ओर point करना चाहिए; att_02 को सीधे att_01 की ओर भी point करना चाहिए, क्योंकि उसी attempt ने इसे trigger किया था।

Conversation ID को operation ID न बनाएं। एक agent conversation में कई actions हो सकते हैं, और कोई action conversation से अधिक समय तक चल सकता है जब supervisor काम फिर शुरू करे। Request hash को भी अकेली identity न बनाएं। Hash bytes का वर्णन करता है, जबकि operation intended effect का। दो requests में transport से जुड़े मामूली अंतर हो सकते हैं और फिर भी वे एक ही operation का हिस्सा हो सकती हैं। इसके उलट, agent जानबूझकर एक ही bytes दो बार भेजे तो वे दो अलग intended actions हो सकते हैं।

Operation identity तब बनाएं जब agent कोई commitment तय करे, जैसे «account A disable करें», «alert B के लिए एक incident बनाएं» या «host C पर यह migration एक बार चलाएं»। इस intent को structured fields में दर्ज करें। साधारण natural-language summary लोगों के लिए उपयोगी है, लेकिन वह अकेली identity नहीं हो सकती, क्योंकि अलग agent runs में wording बदलती रहती है।

एक साफ hierarchy इस तरह दिखती है:

• Session एक agent process run की पहचान करता है।
• Operation एक intended external effect की पहचान करता है।
• Attempt एक actual execution try की पहचान करता है।
• Observation बाद में मिले evidence की पहचान करता है, जैसे callback, read-after-write check या operator decision।

यह hierarchy एक आम मुश्किल स्थिति सुलझाती है: agent request भेजता है, timeout होता है, फिर किसी दूसरे endpoint से पूछता है कि action हुआ या नहीं। Lookup retry नहीं है। यह original operation से जुड़ा observation है। इसे एक और attempt मानने पर सबसे उपयोगी evidence गलत bucket में दब जाता है।

Unknown एक outcome है, error message नहीं

Timeout uncertainty पैदा करता है, failure का प्रमाण नहीं। आपके log में उस uncertainty के लिए state होनी चाहिए और बाद का evidence उसे resolve करे तब तक उसे बनाए रखना चाहिए।

कई client libraries कई घटनाओं को एक exception में मिला देती हैं: connection refused, DNS failure, बहुत देर से आया response body और server द्वारा write commit करने के बाद connection reset। Application control flow के लिए यह सुविधा ठीक है। Final audit record के रूप में यह स्वीकार्य नहीं है। Records में यह साफ होना चाहिए कि caller ने क्या देखा, और destination के बारे में ऐसे दावे नहीं होने चाहिए जिन्हें caller साबित नहीं कर सकता।

Attempt के लिए local observation और resolved operation state को अलग रखें। Attempt not_sent, sent_no_response, response_received या execution_error हो सकता है। Operation open, succeeded, failed, unknown या cancelled हो सकता है। नाम अलग हो सकते हैं, लेकिन यह separation नहीं बदलना चाहिए।

not_sent का अर्थ है कि client ने dispatch से पहले रुक गया। Local credential lookup failure इसका उदाहरण हो सकता है। इसे retry करने से remote side effect duplicate नहीं हो सकता, क्योंकि कोई remote request गई ही नहीं।

sent_no_response का अर्थ है कि caller ने action dispatch किया, लेकिन उसके पास usable response नहीं है। यही खतरनाक state है। Automatic retry तभी सुरक्षित हो सकती है जब destination के पास भरोसेमंद deduplication mechanism हो या action खुद duplicate effect पैदा न कर सकता हो।

response_received का अर्थ अपने-आप success नहीं होता। Server validation error, conflict response या asynchronous work बताने वाला success response लौटा सकता है। Status, relevant response fingerprint और destination द्वारा दिया गया operation reference सुरक्षित रखें। फिर उस particular API के contract के आधार पर operation state तय करें।

जब आपका मतलब unknown हो तो failed न लिखें। इससे dashboards साफ दिखते हैं, लेकिन अगले agent या operator को ऐसा action दोहराने का संकेत मिलता है जो शायद पहले ही हो चुका है। Incident के दौरान यह एक बेईमान field एक गलत action को पूरी श्रृंखला में बदल सकती है।

HTTP semantics business action को दोहराने के लिए सुरक्षित नहीं बनाते

HTTP methods protocol semantics बताते हैं, आपके business guarantees नहीं। RFC 9110 के अनुसार method idempotent तब होता है जब कई समान requests का intended effect एक request के effect जैसा ही हो। इसमें PUT, DELETE और safe methods को idempotent बताया गया है, जबकि POST default रूप से idempotent नहीं है।

यह guidance उपयोगी है, लेकिन engineers इसे जरूरत से ज़्यादा लागू करते हैं। DELETE request protocol के स्तर पर idempotent हो सकती है, क्योंकि missing resource को delete करने पर वह missing ही रहती है। आपके audit का सवाल अलग हो सकता है: क्या agent ने सही account delete किया, क्या उसने downstream cleanup दो बार trigger किया और क्या दूसरी call में अलग authority इस्तेमाल हुई? Protocol label इन सवालों का उत्तर नहीं देता।

PUT भी समस्या पैदा करता है। Resource को fixed representation पर set करने वाला PUT अक्सर retries सह लेता है। लेकिन ऐसा PUT endpoint जो हर receipt पर notification भेजता है, record allocate करता है या integration चलाता है, वह वह सुरक्षा नहीं देता जिसकी लोग उम्मीद करते हैं। Destination का documented contract पढ़ें और response loss को जानबूझकर पैदा करके behavior test करें। Method names evidence नहीं होते।

POST endpoints अक्सर idempotency token support करते हैं। Attempt ID से नहीं, operation ID से निकला stable token भेजें। अगर att_01 और att_02 के tokens अलग हैं, तो आपने उस feature को ही निष्क्रिय कर दिया जो retry से बचाता है।

Request envelope कुछ इस तरह दिख सकता है:

{
  "operation_id": "op_7f2c9c",
  "attempt_id": "att_01",
  "idempotency_key": "op_7f2c9c",
  "intent": {
    "kind": "disable_account",
    "subject_ref": "user:1842"
  },
  "destination": {
    "method": "POST",
    "route_template": "/v1/accounts/{id}/disable",
    "authority_ref": "vault:identity-prod"
  },
  "request_fingerprint": "sha256:...",
  "dispatch_state": "sent_no_response"
}

Authorization header, session cookie, private SSH material या secrets वाली body log न करें। Credential reference और canonical request representation का fingerprint दर्ज करें। Fingerprint investigators को attempts की तुलना करने देता है, बिना audit trail को एक और secret store बनाए।

Destination को idempotency token का सम्मान करना होगा, तभी वह repeat effects रोक पाएगा। ऐसा होने पर destination का returned reference और यह दर्ज करें कि response stored prior result से आया था या नहीं। अगर destination token का सम्मान नहीं करता, तो वह केवल inert header है और आपकी retry policy को उसी के अनुसार काम करना होगा।

SSH retry एक से अधिक commands दोहरा सकता है

SSH retry accounting को कठिन बनाता है, क्योंकि एक connection में shell syntax, pipelines, redirects और आंशिक रूप से पूरे हुए commands हो सकते हैं। Failed SSH session यह नहीं बताती कि remote command के कौन-से हिस्से चले।

इस command पर विचार करें:

create-user deployer && install-key deployer /tmp/new.pub && restart-service api

अगर dispatch के बाद client connection खो देता है, तो retry इसलिए fail हो सकती है कि user पहले ही मौजूद है, helper key को append करता हो तो वह उसे दो बार install कर सकती है, या service को दूसरी बार restart कर सकती है। Shell का && केवल एक execution के भीतर behavior नियंत्रित करता है। नई connection से पूरी string दोबारा चलने पर यह कोई सुरक्षा नहीं देता।

Exact command तभी log करें जब उसमें कोई secret material न हो। अन्यथा redacted display form और canonical fingerprint रखें। Host alias या host key reference, remote account reference, relevant होने पर working directory, मिला हुआ exit status और execution boundary दर्ज करें। Boundary में यह स्पष्ट होना चाहिए कि helper ने command शुरू की थी या नहीं और उसे exit status मिला था या नहीं, केवल यह नहीं कि local caller ने error बताया था।

सुरक्षित pattern ऐसा remote script है जिसमें operation marker हो और action से पहले script उसे check करे। Marker ऐसी जगह रहना चाहिए जिसे target system atomically पढ़ सके। Environment के अनुसार database transaction, deployment record या exclusive creation से बनाई गई file काम कर सकती है। Local agent cache process crash या दूसरे agent run के बाद कुछ साबित नहीं कर सकती।

उदाहरण के लिए, deployment script OPERATION_ID स्वीकार कर सकती है, activation से पहले उसे release record में लिख सकती है और record पहले से मौजूद हो तो existing result लौटा सकती है। Audit event तब local operation ID और remote record ID दोनों दर्ज करता है। इससे investigator को agent record और host पर मौजूद evidence के बीच पुल मिलता है।

Arbitrary shell commands को «mostly safe» होने के कारण retryable न मानें। Command families को categories में बाँटें। Read-only collection को freely retry किया जा सकता है। State-setting commands के लिए स्पष्ट convergence condition चाहिए। Append-only, financial, destructive या notification commands के लिए remote deduplication record या unknown result के बाद human decision चाहिए।

हर बाद के attempt का स्पष्ट कारण और parent होना चाहिए

Retry event में उस attempt का नाम होना चाहिए जिसने इसे trigger किया और उस condition का भी जिसने दूसरी कोशिश को उचित बनाया। retry_count: 2 बहुत कम जानकारी देता है। इससे पता चलता है कि पहले calls हुई थीं, लेकिन यह नहीं कि कौन-सी call fail हुई, agent ने कुछ बदला या नहीं, या किसी human ने आगे बढ़ने की मंज़ूरी दी थी।

Controlled reasons का एक set रखें और supporting details अलग से जोड़ें। उपयोगी reasons में connection_not_established, rate_limited, destination_5xx, response_lost_after_dispatch, credential_refreshed और operator_requested शामिल हैं। Agent को ऐसा prose reason गढ़ने न दें जो आश्वस्त करने वाला दिखे लेकिन group या review न किया जा सके।

हर retry के लिए ये links सुरक्षित रखें:

{
  "operation_id": "op_7f2c9c",
  "attempt_id": "att_02",
  "retry_of_attempt_id": "att_01",
  "retry_reason": "response_lost_after_dispatch",
  "retry_decision": "destination_idempotency_confirmed",
  "attempt_budget_remaining": 1,
  "request_fingerprint": "sha256:...",
  "prior_request_fingerprint": "sha256:..."
}

आमतौर पर दोनों fingerprints समान होने चाहिए। अलग हों तो कारण log करें। बदला हुआ timestamp header अपेक्षित हो सकता है। बदला हुआ account identifier, amount, hostname, route या authority सामान्य अर्थ में retry नहीं है। यह नया operation या manually amended intent है, और audit trail को यह साफ कहना चाहिए।

यहीं agent systems अक्सर खुद को गुमराह करते हैं। Model error पढ़ता है, उसे «ठीक» करने के लिए parameter बदलता है और अगली request को retry कहता है। यह नए संभावित effect वाला नया decision है। इसे retry के रूप में link करने से plan में बदलाव छिप जाता है और review लगभग असंभव हो जाता है।

हर operation के लिए attempt budget सीमित करें और budget decision रिकॉर्ड करें। Destination के बताए delay के बाद rate-limit response को retry करना और timeout के बाद unknown write को retry करना अलग बातें हैं। पहले मामले में remote response अक्सर स्पष्ट होता है। दूसरे में दोहराने से पहले idempotency evidence या reconciliation चाहिए।

Idempotency tokens और audit identities अलग काम करते हैं

Idempotency token destination से कहता है कि repeated submissions को एक operation माना जाए। Audit operation ID आपके investigators को बताती है कि कौन-से attempts एक intent से जुड़े हैं। संभव हो तो दोनों का इस्तेमाल करें, लेकिन यह न मानें कि एक दूसरे की जगह ले सकता है।

Token किसी route, merchant, time window या particular account तक सीमित हो सकता है। कुछ APIs tokens को केवल सीमित अवधि तक रखते हैं। कुछ duplicate के लिए original response लौटाती हैं, कुछ conflict लौटाती हैं। Request body बदलने पर कुछ APIs reused token अस्वीकार करती हैं। ये details connector contract और test suite में होनी चाहिए।

आपकी operation ID की भूमिका व्यापक है। यह agent session, approval evidence, request construction, transport attempts, remote response और बाद की reconciliation को जोड़ती है। Vendor API idempotency न दे, action SSH से हो या operator final recovery manually करे, operation ID तब भी valid रहनी चाहिए।

Process memory गायब हो जाने के कारण restart के बाद नई operation ID न बनाएं। Dispatch से पहले pending operations persist करें। Recovery पर हर unresolved operation देखें और तीन में से एक रास्ता चुनें: remote evidence से reconcile करें, documented idempotency guarantee के तहत retry करें या किसी व्यक्ति तक मामला पहुँचाएं। Restart engineering event है, uncertainty भूल जाने की अनुमति नहीं।

हर failed write को exponential backoff के साथ retry करने की लोकप्रिय सलाह गलत है। Backoff struggling service पर pressure कम करता है। वह unknown write को safe write में नहीं बदलता। दूसरी कोशिश स्वीकार्य है या नहीं, यह action की repeatability और destination के deduplication behavior से तय होता है।

Reconciliation इतिहास बदले बिना uncertainty बंद करती है

Reconciliation का अर्थ unresolved operation के बारे में बाद का evidence जुटाना है। इसका अर्थ पहली attempt को edit करके successful दिखाना नहीं है।

मान लीजिए agent request body में client-provided reference के साथ incident बनाता है। Initial POST sent_no_response पर खत्म होती है। Retry से पहले agent उस reference से incidents query करता है। अगर उसे matching record मिलती है, तो original operation ID, query fingerprint, returned remote identifier और match criteria का उल्लेख करने वाला observation event जोड़ें। फिर reconciliation के माध्यम से operation को succeeded के रूप में close करें।

अगर query को कुछ नहीं मिलता, तो सावधान रहें। API में replication delay, search indexing lag या weak filtering हो तो absence बहुत कम साबित करती है। Negative observation को इस्तेमाल किए गए समय और endpoint के साथ दर्ज करें। तभी retry करें जब destination का contract कहता हो कि idempotency token अभी प्रभावी है, या प्रतीक्षा करके decision लें।

अगर query को दो matching records मिलें, तो operation को succeeded कहकर आगे न बढ़ें। इसे duplicate_effect_confirmed के रूप में close करें, दोनों remote identifiers सुरक्षित रखें और अलग remediation operation बनाएं। Remediation को original operation ID साझा नहीं करनी चाहिए, क्योंकि उसका intended effect अलग है।

Mutable status rows की जगह append-only events को source of truth रखें। User interface के लिए convenient current status project किया जा सकता है, लेकिन evidence में transitions सुरक्षित रहने चाहिए: intent created, attempt dispatched, response lost, lookup performed, remote record found, operation resolved। Investigator को पूरी sequence चाहिए, जिसमें हुई गलत retry भी शामिल है।

Tamper-evident log एक और गुण देता है: इससे आप verify कर सकते हैं कि बाद की process ने पहली unknown attempt को चुपचाप हटाया नहीं। Sallyport agent sessions और individual actions को write-blind encrypted, hash-chained audit log से record करता है, और sp audit verify ciphertext पर offline chain check करता है। इससे timeline सुरक्षित रखने में मदद मिलती है, लेकिन event schema में operation और attempt links फिर भी चाहिए।

Agent delegation में एक operation owner होना चाहिए

Subagents duplicate effects को आसान बना देते हैं, क्योंकि हर process मान सकता है कि task उसी का है। Operation ID का owner एक process को बनाएं और हर delegated worker से कहें कि वह अपने action context में वही ID रखे।

Planner एक worker से information gather करने और दूसरे worker से action execute करने को कह सकता है। Information-gathering calls को अपनी operations मिलनी चाहिए, क्योंकि वे अलग intents हैं। Execution worker को original operation ID तभी दें जब वह उसी declared effect पर काम कर रहा हो। उसकी individual calls fresh attempt IDs इस्तेमाल करें और call करने वाले worker process की पहचान दें।

Workers को unknown write का independent retry करने न दें, जबकि parent भी उसे retry कर रहा हो। Parent को तय करने से पहले worker की dispatch state मिलनी चाहिए। Worker अचानक बंद हो जाए तो operation को unresolved mark करें और reconcile करें। Missing child result supervisor को command replay करने का निमंत्रण नहीं है।

Per-session approval records भी evidence chain का हिस्सा हैं। जब agent process को calls के group की authority मिलती है, तो process identity, approval time और revocation time को action outcome से अलग log करें। Approval बताता है कि किसे try करने की अनुमति थी। इससे यह साबित नहीं होता कि destination ने action किया।

Sensitive operations के लिए, first attempt का outcome unknown होने पर retry के लिए per-call approval मांगें। Approval card में original intent, previous dispatch state और planned recovery method लिखे हों तो लोग बेहतर decision लेते हैं। «allow API call» जैसा generic prompt उस एक तथ्य को छिपा देता है जिस पर उन्हें रुककर सोचना चाहिए।

Investigation view में requests का ढेर नहीं, timeline दिखनी चाहिए

Investigator को एक ऐसा operation page या query result चाहिए जो intent से शुरू होकर best-supported outcome पर खत्म हो। Time के अनुसार sorted request logs reviewer को दबाव में parentage खुद reconstruct करने पर मजबूर करते हैं, अक्सर अलग-अलग systems में जिनकी clocks थोड़ी अलग होती हैं।

ऊपर operation state दिखाएं, लेकिन नीचे evidence उपलब्ध रखें। हर attempt में उसका number, dispatch state, retry parent, reason, authority reference, destination, request fingerprint, response summary और duration दिखना चाहिए। हर observation में यह दिखना चाहिए कि उसने क्या check किया और उस evidence ने state को बदला या न बदलने का कारण क्या था।

Final effect harmless होने पर duplicate requests को छिपाएं नहीं। आज की harmless duplication API बदलने या integration में webhook जुड़ने के बाद महंगा side effect बन सकती है। Record reviewers को «agent ने सही retry की और destination ने deduplicate किया» तथा «agent ने request दो बार भेजी और वह संयोग से ठीक रहा» के बीच अंतर दिखाए।

Recovery के दौरान request body बदलना explicit fork मानें। Original operation open रहे या उसे resolved outcome मिले। Amended action को नई operation ID और supersedes_operation_id जैसा link दें। यह record सच बताता है: agent ने केवल retry नहीं किया, उसने अपना intended action बदल दिया।

Design पर भरोसा करने से पहले एक forced-failure test बनाएं। Destination से known idempotent test action commit करवाएं, फिर caller को response मिलने से पहले उसे drop कर दें। Confirm करें कि अगला agent run original operation ID रखता है, वही destination token इस्तेमाल करता है, पहली unknown attempt log करता है, documented reconciliation या retry करता है और evidence के साथ operation close करता है। अगर आपका test इन सवालों का जवाब नहीं दे सकता, तो incident भी नहीं देगा।

Agent action log में मैं सबसे पहले HTTP status नहीं देखता। मैं stable operation ID देखता हूं। इसके बिना हर retry investigation guesswork से शुरू होती है। इसके साथ आप महत्वपूर्ण सवाल पूछ सकते हैं: agent का intent क्या था, machine से क्या बाहर गया, attempts के बीच क्या बदला और final outcome को कौन-सा evidence support करता है।