रद्द हुई एजेंट कार्रवाइयों को बिना झूठ बोले कैसे दर्ज करें

हर canceled agent action को «failed» बताने वाला ऑडिट लॉग झूठ बोलता है। एजेंट ने इंतजार करना बंद कर दिया हो सकता है, लेकिन database row पहले ही बन चुकी हो सकती है, deployment शुरू हो चुका हो सकता है या connection टूटने के बाद भी remote command चल रही हो सकती है।

समाधान failure codes की लंबी सूची नहीं है। जरूरत ऐसे outcome model की है जो गेटवे ने जो देखा और destination पर जो हुआ, उन्हें अलग रखे। जांचकर्ताओं को यह अंतर समझना चाहिए कि कौन-सी कार्रवाई मशीन से निकली ही नहीं, किसे destination ने अस्वीकार किया, कौन-सी receipt के साथ पूरी हुई और किसका प्रभाव अब भी अज्ञात है।

Caller का result, action का result नहीं होता

कॉलर कार्रवाई का केवल छोटा हिस्सा देखता है: वह काम भेजता है और जवाब का इंतजार करता है। कार्रवाई खुद कई ऐसे सिस्टम से गुजरती है जिनकी clock, process lifetime या भरोसेमंद return path एक जैसा नहीं होता। जब caller cancel करता है, disconnect होता है या deadline तक पहुंचता है, तो उसे अपनी waiting के बारे में जानकारी मिलती है। इससे remote effect के बारे में अंतिम जानकारी जरूरी नहीं मिलती।

यह अंतर state बदलने वाले काम में सबसे महत्वपूर्ण है। Ticket बनाना, refund जारी करना, infrastructure changes लागू करना, object हटाना, access token बदलना और remote command चलाना, इन सबके परिणाम missing response के बाद भी बने रह सकते हैं। अगर agent process पहले बंद होने पर आपका journal failed लिखता है, तो बाद की retry दूसरा ticket बना सकती है, दूसरा refund जारी कर सकती है या destructive command दो बार चला सकती है।

Read operations में भी यही ईमानदारी चाहिए, हालांकि जोखिम अलग है। Canceled fetch अधूरा view लौटा सकता है और एजेंट गलत अगला निर्णय ले सकता है। आम तौर पर इससे अपने-आप दुनिया में बदलाव नहीं होता। POST, PATCH, DELETE या remote shell command ऐसा कर सकते हैं।

हर record में तीन बातें अलग रखें:

• Caller disposition: completed, canceled, disconnected या timed out।
• Dispatch evidence: never started, started locally, bytes handed to transport या receipt confirmed by the remote side।
• Effect outcome: no effect, succeeded, rejected, partially completed या unknown effect।

टीमें अक्सर पहले और तीसरे field को मिला देती हैं, क्योंकि एक status column सुविधाजनक लगता है। यह सुविधा incident review तक रहती है। फिर किसी को समझाना पड़ता है कि «request canceled» के साथ production में वह object क्यों मौजूद है।

व्यावहारिक नियम सीधा है: no effect तभी लिखें जब प्रमाण execution को खारिज करता हो। जब execution संभव हो और भरोसेमंद result न मिला हो, unknown effect लिखें। Unknown लॉग की शर्मनाक कमी नहीं है। यह उस distributed action का सटीक परिणाम है जिसकी observation path बीच में टूट गई।

अनुमानित कहानी नहीं, प्रमाण की सीमा दर्ज करें

हर कार्रवाई के लिए ऐसी स्पष्ट सीमा चाहिए जिसके बाद गेटवे ईमानदारी से यह वादा नहीं कर सकता कि कुछ नहीं हुआ। इसे dispatch boundary कहें। HTTP में यह वह क्षण हो सकता है जब request connection पर commit होकर operating system को सौंप दी जाती है, या जब upstream service acceptance की पुष्टि करती है। SSH में यह वह क्षण हो सकता है जब helper authenticated channel पर command request भेज देता है।

यह न मानें कि एक sent=true Boolean से सब तय हो जाता है। Local writes buffer हो सकते हैं। Transport library peer application द्वारा data पढ़े जाने से पहले write report कर सकती है। Peer request पा सकता है, change लागू कर सकता है और लौटते समय response खो सकता है। लॉग में उपलब्ध सबसे मजबूत प्रमाण लिखें, implementation detail को proof न बनाएं।

एक उपयोगी action record में immutable identifiers और observations का क्रम होता है। यह shape API call और command execution दोनों के लिए काम करती है:

{
  "action_id": "act_01JQ7M4V6K",
  "session_id": "ses_01JQ7M2Y8A",
  "channel": "http",
  "intent": {
    "method": "POST",
    "target": "api.example.internal/v1/releases",
    "request_fingerprint": "sha256:...",
    "idempotency_token": "release_01JQ7M4V6K"
  },
  "observations": [
    {"at": "2026-07-22T16:40:01Z", "kind": "authorized"},
    {"at": "2026-07-22T16:40:02Z", "kind": "dispatch_started"},
    {"at": "2026-07-22T16:40:03Z", "kind": "transport_write_completed"},
    {"at": "2026-07-22T16:40:33Z", "kind": "caller_deadline_exceeded"}
  ],
  "caller_disposition": "timed_out",
  "effect_outcome": "unknown_effect",
  "outcome_basis": "response_not_observed_after_dispatch"
}

Request fingerprint यह पहचानता है कि क्या आजमाया गया, लेकिन bearer credential, raw request body या secret command argument को journal में रखने की जरूरत नहीं पड़ती। यह identifier retries और बाद की reconciliation में स्थिर रहना चाहिए। अगर operator original request, उसकी retry और अंततः बने remote object को जोड़ नहीं सकता, तो audit trail असली सवाल का जवाब नहीं देता।

dispatch_started और transport_write_completed में महत्वपूर्ण अंतर है। पहला बताता है कि गेटवे ने operation शुरू किया। दूसरा बताता है कि उसके local transport ने outbound data स्वीकार कर लिया। इनमें से कोई भी यह नहीं बताता कि remote application ने उसे execute किया। अगर implementation इन दोनों को अलग नहीं कर सकती, तो कमजोर तथ्य दर्ज करें और outcome basis में यह स्पष्ट करें।

Dispatch से पहले cancellation का मतलब no effect हो सकता है

Cancellation no-effect निष्कर्ष का आधार बन सकती है, लेकिन केवल तब जब गेटवे action को बाहरी channel पर commit करने से पहले उसे रोक दे। यह साफ स्थिति है: agent local authorization का इंतजार करते हुए request वापस ले, vault unlock होने से पहले, HTTP request शुरू होने से पहले या SSH command transport helper को दिए जाने से पहले।

ऑडिट entry में यह भी दिखना चाहिए कि निष्कर्ष सुरक्षित क्यों है। केवल «Canceled» से जांचकर्ता यह नहीं समझ सकता कि cancellation किस stage पर हुई। Stage और local proof point लिखें।

{
  "action_id": "act_01JQ7P1N2R",
  "caller_disposition": "canceled",
  "effect_outcome": "no_effect",
  "outcome_basis": "cancellation_observed_before_dispatch",
  "last_observed_stage": "awaiting_authorization"
}

जब local gate किसी बाहरी request से पहले action को रोक देता है, तब भी यही result उचित है। Missing approval, locked vault, revoked session या invalid local request no effect दे सकते हैं, बशर्ते गेटवे ने काम dispatch न किया हो। Journal को denied request और canceled request अलग रखने चाहिए, क्योंकि वे human control और agent behavior के बारे में अलग बातें बताते हैं। फिर भी दोनों में सुरक्षित रूप से कहा जा सकता है कि target ने कुछ नहीं देखा।

Connection बनाने और लिखना शुरू करने के बाद यह label न लगाएं, भले ही transport call cancellation error लौटाए। कई libraries कई paths के लिए एक ही error value इस्तेमाल करती हैं: queue में रहते cancellation, write के दौरान cancellation, response headers का इंतजार करते हुए cancellation या body पढ़ते समय cancellation। ये एक जैसे नहीं हैं।

Cancellation propagation उपयोगी है, लेकिन यह time machine नहीं है। gRPC cancellation guidance कहती है कि client cancellation से संकेत मिलता है कि उसे RPC result की जरूरत नहीं रही और servers को काम रोककर downstream work तक cancellation पहुंचानी चाहिए। यह resource hygiene के लिए अच्छा है। इससे यह साबित नहीं होता कि पहले का side effect वापस हो गया, और independently committed write को यह undo नहीं कर सकता।

अगर receiving service operation identifier से जुड़ा explicit cancellation endpoint देती है, तो उसे दूसरी action के रूप में दर्ज करें। उसका result original effect outcome तभी बदल सकता है जब service original operation के बारे में भरोसेमंद statement दे। Network break के बाद लौटने वाली best-effort cancel request एक और unknown effect बनाती है। वह जादू से पहली कार्रवाई को साफ नहीं करती।

Dispatch के बाद timeout का effect unknown होता है

Deadline इंतजार करने की स्थानीय सीमा है। यह remote execution पर verdict नहीं है। Action dispatch boundary पार कर जाए तो timeout का default unknown effect होना चाहिए, जब तक protocol receipt या बाद की जांच कुछ और साबित न करे।

HTTP में इसे गलत समझना आसान है, क्योंकि status labels अंतिम जैसे लगते हैं। RFC 9110 के अनुसार 408 का अर्थ है कि server को जितनी देर इंतजार करना था, उसमें पूरी request message नहीं मिली। 504 का अर्थ है कि gateway को upstream server से समय पर response नहीं मिला। दोनों statements एक observer और एक exchange का वर्णन करते हैं। इनमें से कोई यह साबित नहीं करता कि अलग system ने पहले से मिले data पर काम नहीं किया।

मान लें agent 30 second deadline के साथ POST /v1/releases भेजता है। API request validate करती है, release row insert करती है, deployment controller को start करने को कहती है और response बनाते समय अटक जाती है। 30 seconds पर agent timeout देखता है। Release मौजूद है। Idempotency token के बिना retry दूसरी release बना सकती है, भले ही agent transcript में पहली call «failed» लिखी हो।

सच्चा record ऐसा दिखेगा:

{
  "caller_disposition": "timed_out",
  "effect_outcome": "unknown_effect",
  "outcome_basis": "deadline_after_transport_write_no_remote_receipt",
  "recovery_required": "lookup_by_idempotency_token"
}

Unknown के लिए failed को shortcut की तरह इस्तेमाल न करें। Failure outcome केवल उन facts के लिए रखें जिन्हें आप साबित कर सकते हैं: remote service ने validation error लौटाया, command ने nonzero exit status दिया, कोई request gateway से निकलने से पहले connection स्थापित नहीं हो सकी या local authorization ने execution रोक दी। Outbound dispatch संभव होने के बाद timeout इस मानक को पूरा नहीं करता।

जब remote side प्रमाण दे, तब partial completion का अपना outcome रखें। Batch APIs और scripts अक्सर fail होने से पहले कुछ काम कर देते हैं। अगर service completed object IDs की सूची और फिर error लौटाती है, तो partial_effect दर्ज करें, policy के अनुसार object IDs सुरक्षित रखें और service का बताया कारण capture करें। इसे केवल «failed» कहना operator के जरूरी cleanup को छिपा देता है।

Lost acknowledgments के लिए अलग record रखें

Lost acknowledgment तब होता है जब receiver ने काम किया हो सकता है, लेकिन final receipt मिलने से पहले गेटवे connection खो देता है। यह इतना आम है कि इसे generic network error के बजाय नाम वाली observation मिलनी चाहिए।

क्रम आम तौर पर आखिरी क्षण तक सामान्य दिखता है:

1. गेटवे action को authorize और dispatch करता है।
2. Remote service उसे स्वीकार करके requested work करती है या queue में रखती है।
3. Response देर से आता है, connection टूटता है या local process बंद हो जाती है।
4. गेटवे के पास completion का durable proof नहीं होता, जबकि remote system के पास हो सकता है।

पहली गलती यह है कि बाद की lookup सफल होने पर original entry को overwrite कर दिया जाए। इससे journal ऐसा दिखता है जैसे गेटवे को उसी समय outcome पता था। जांचकर्ता को दोनों facts चाहिए: initial call acknowledgment के बिना खत्म हुई और बाद की reconciliation में matching remote result मिला।

इसके बजाय observation जोड़ें:

{
  "action_id": "act_01JQ7M4V6K",
  "reconciliation": {
    "at": "2026-07-22T16:43:10Z",
    "method": "GET /v1/operations/release_01JQ7M4V6K",
    "remote_reference": "op_8f2c",
    "result": "succeeded"
  },
  "effect_outcome": "succeeded",
  "outcome_basis": "remote_operation_lookup"
}

Original caller disposition timed_out ही रहे। उसे completed न लिखें। Caller सचमुच timeout हुआ था। System ने बाद में जाना कि remote action सफल रही। दोनों facts में कोई विरोधाभास नहीं है।

Remote receipt उतनी ही भरोसेमंद है जितना उसका correlation। Object name, current timestamp या agent की natural language पर matching कमजोर है। Target द्वारा स्वीकार किया गया idempotency token, long-running work शुरू होने से पहले लौटाया गया operation ID या target द्वारा request के लिए unique guaranteed provider request ID बेहतर हैं। अगर destination इनमें से कुछ नहीं देती, तो सीमित read-back query इस्तेमाल करें और दर्ज करें कि वह क्यों पर्याप्त है या ambiguity क्यों बनी हुई है।

मसलन, build-bot नाम का नया user मिलना यह साबित नहीं करता कि उसे किस create request ने बनाया। Original action token के बराबर stored request token वाला object मिलना कहीं बेहतर है। इसी अंतर से तय होता है कि retry सुरक्षित है या नहीं।

Idempotency recovery को जुए के बजाय जांच बना देती है

Idempotency बाद में जोड़ा गया retry permission slip नहीं है। यह dispatch से पहले तय किया गया contract है। Client stable token देता है और service गारंटी देती है कि उसी token वाली repeated requests नई effects बनाने के बजाय उसी logical operation को पहचानेंगी।

हर state बदलने वाले HTTP integration के लिए service owner से चार सीधे सवाल पूछें:

• क्या वह caller-supplied idempotency token स्वीकार करती है?
• Token दोहराने पर request के कौन-से fields बिल्कुल समान रहने चाहिए?
• Token-to-result mapping कितने समय तक रखी जाती है?
• Lost response के बाद caller original result वापस पा सकता है?

अगर जवाब अस्पष्ट हों, तो automatic retry को सुरक्षित न बताएं। «हम आम तौर पर deduplicate करते हैं» contract नहीं है। Cache eviction, regional failover या request parser में बदलाव इस धारणा को duplicate work में बदल सकते हैं।

जहां target idempotency support नहीं करता, वहां जोखिम वाली operation को संभव हो तो अलग चरणों में बांटें। Unique external reference वाला durable draft बनाएं, उसे verify करें और फिर लौटे identifier के आधार पर irreversible command चलाएं। इससे हर operation सुरक्षित नहीं हो जाती, लेकिन महंगे या destructive हिस्से से पहले reconciliation point बन जाता है।

Deployment workflow इसका अंतर दिखाता है। Create और start दोनों करने वाला one-shot endpoint lost acknowledgment के बाद recovery की बहुत कम जगह छोड़ता है। Two-call workflow action ID को external reference बनाकर release create कर सकता है, timeout के बाद उस reference को query कर सकता है और known release ID मिलने के बाद ही उसे start कर सकता है। यह अतिरिक्त call आम तौर पर unexpected production change समझाने से सस्ती होती है।

उसी action की automatic retry के लिए कभी नया idempotency token न बनाएं। नया token बताता है कि retry नई logical request है। जब कोई इंसान जानबूझकर काम दोहराता है, तब यह सही हो सकता है, लेकिन recovery के दौरान deduplication खत्म हो जाती है। Original token को action record के साथ रखें और retry में parent action ID का हवाला दें।

Idempotency contract incident response में भी मदद करता है। जांचकर्ता एक ठोस सवाल पूछ सकते हैं: «Token X के लिए target ने क्या तय किया?» इसके बिना उन्हें timestamps, logs और names से intent का अनुमान लगाना पड़ता है। यह धीमा, error-prone और retention window बीतने के बाद अक्सर असंभव होता है।

SSH closure और command completion अलग facts हैं

SSH में भी यही गलती होती है, क्योंकि बंद session बंद हुई command जैसा लगता है। ऐसा जरूरी नहीं है। Network break client को रोक सकता है, जबकि remote process अपने parent shell, supervisor या service manager के तहत चलती रहे। दूसरी ओर process खत्म हो सकती है, लेकिन client exit report खो सकता है।

RFC 4254 channel closure, end of file और exit status को अलग protocol events मानता है। यह remote command खत्म होने पर exit status लौटाने की सलाह देता है, लेकिन channel close को मिला हुआ exit status नहीं मानता। Specification यह भी कहती है कि peers channel को closed मानने से पहले close messages भेजते हैं। इससे SSH channel state पता चलती है, remote command ने channel टूटने से पहले filesystem या service में क्या बदलाव किया, यह नहीं।

SSH evidence को अलग observations के रूप में दर्ज करें:

{
  "channel": "ssh",
  "observations": [
    {"kind": "command_request_sent"},
    {"kind": "stdout_received", "bytes": 1840},
    {"kind": "connection_lost"}
  ],
  "caller_disposition": "disconnected",
  "effect_outcome": "unknown_effect",
  "outcome_basis": "no_exit_status_or_remote_process_identity"
}

अगर command के output के बाद valid exit status और complete channel close मिल जाए, तो command process के बारे में मजबूत evidence है, हालांकि उसके शुरू किए हर external side effect का पूर्ण proof नहीं। Script asynchronous work submit करके काम पूरा होने से पहले zero exit कर सकती है। Command outcome को succeeded लिखें और अगर remote system ID देती है, तो external job को अलग operation मानें।

Agent के command चलाने से पहले recovery plan होना चाहिए। ऐसी commands को प्राथमिकता दें जो durable operation identifier print या write करें। Service restart के लिए known unit name से service manager query करें और पहले तथा बाद की state देखें। Database migration के लिए terminal output पर भरोसा करने के बजाय migration ledger देखें। File operation के लिए केवल path मौजूद है या नहीं, यह न जांचें, content hash और version या generation marker भी देखें।

Local helper को भेजे गए signal को remote process के रुकने का proof न मानें। Signal remote dispatch से पहले, remote command पूरी होने के बाद या connection टूटने के बाद पहुंच सकता है। Signal को caller या gateway event के रूप में log करें। Effect outcome तभी बदलें जब remote endpoint प्रमाण दे।

जांच final label से नहीं, chronology से शुरू होती है

जांचकर्ता को indeterminate action को बिना यह अनुमान लगाए reconstruct कर पाना चाहिए कि कौन-सी log line पहले आई। इसके लिए stable action ID, session ID, gateway के भीतर monotonic event ordering और observed events के timestamps चाहिए। Wall-clock time correlation में मदद करता है, लेकिन systems के बीच drift हो सकता है। पूरी conclusion को इस बात पर न टिकाएं कि दो clocks millisecond तक मिल रही हैं।

एक अच्छी जांच क्रम से ये सवाल पूछती है:

1. Action को किसने authorize किया और request किस agent process ने की?
2. क्या gateway ने dispatch boundary पार की?
3. Dispatch के बाद कौन-सी transport observations हुईं?
4. क्या कोई trusted remote receipt आई?
5. अगर नहीं, तो original logical operation पहचानने के लिए कौन-सी reconciliation query चल सकती है?

यह क्रम एक आम बुरी आदत रोकता है: पहले remote logs खोजना, मिलता-जुलता event पाना और उसे जवाब घोषित कर देना। Intended action और उसकी correlation material से शुरुआत करें। फिर जांचें कि remote evidence उसी exact operation से मेल खाता है या नहीं।

Audit record को चुपचाप बदलने से बचना चाहिए। अगर operator prior state और update का basis सुरक्षित रखे बिना unknown_effect को succeeded कर सकता है, तो record evidence के बजाय assertion बन जाता है। Append-only records, hash chaining और offline verification post-incident editing छिपाना कठिन बनाते हैं। वे हर remote system के सच बोलने का proof नहीं देते, लेकिन gateway ने क्या और कब देखा, यह सुरक्षित रखते हैं।

Sallyport agent runs और individual actions को एक encrypted, hash-chained audit log से projected अलग journals में रखता है, और sp audit verify ciphertext पर chain को offline verify कर सकता है। यह design यहां उपयोगी है, क्योंकि बाद की reconciliation को नई fact के रूप में दर्ज किया जा सकता है, original timeout या disconnect मिटाए बिना।

Incident response बेहतर बनाने के लिए secret-bearing request bodies को audit trail में न डालें। Sanitized targets, request fingerprints, approved operation identifiers, response classifications और reconciliation के लिए जरूरी न्यूनतम remote references रखें। एक investigation सुलझाने के लिए credentials लीक करने वाला log अगला incident खुद पैदा करता है।

Outcome names को सुरक्षित agent behavior तय करना चाहिए

Outcome taxonomy तभी उपयोगी है जब agent runtime हर result पर अलग प्रतिक्रिया दे। अगर हर non-success तुरंत retry कराता है, तो विस्तृत audit labels सिर्फ सजावट हैं।

इन operational rules का इस्तेमाल करें:

• no_effect के बाद automatic retry तभी करें जब original intent अब भी authorized और current हो।
• rejected के बाद retry तभी करें जब agent invalid input बदले या human बताए गए conflict को हल करे।
• किसी भी state बदलने वाली action को retry करने से पहले unknown_effect की reconciliation करें।
• partial_effect को cleanup या continuation task मानें, खाली शुरुआत नहीं।
• जब reconciliation एक ही matching remote operation पहचान न सके, escalation करें।

आखिरी नियम पर टीमें अधीर हो जाती हैं। वे चाहती हैं कि agent आगे बढ़ता रहे। Read request के लिए यह स्वाभाविक है, लेकिन पैसे खर्च करने, access बदलने, production में बदलाव करने या data हटाने वाली actions के लिए लापरवाही है। Unresolved action तब तक दिखाई देती रहनी चाहिए, जब तक इंसान या भरोसेमंद remote query evidence gap बंद न कर दे।

Approval flow को भी यह अंतर नहीं छिपाना चाहिए। Action मंजूर करने वाला इंसान attempt को मंजूर करता है, unknown result के बाद असीमित retries को नहीं। अगर अगली कोशिश दूसरा effect बना सकती है, तो दिखाएं कि वह indeterminate action की retry है और जोखिम के अनुसार fresh decision लें।

अधिक channels या autonomous behavior जोड़ने से पहले यह model बनाएं। Agent के किसी महत्वपूर्ण बदलाव के बाद आया पहला timeout यह पता लगाने का खराब समय है कि आपके audit log में केवल दो outcomes हैं: success और client ने जो देखा।