Audited agent action के दौरान power loss से outcome अज्ञात रह सकता है

Audited agent action के दौरान power loss से केवल एक failure नहीं बनता। यह evidence की समस्या पैदा करता है। Agent, local gateway, operating system, network और remote service, सभी अलग-अलग चरणों पर रुक सकते हैं। अगर agent को response नहीं मिला और आप इस पूरी उलझन को सिर्फ़ «failed» कहकर समेट देंगे, तो देर-सबेर ऐसा action retry करेंगे जो पहले ही हो चुका है।

यह गलती आसानी से होती है, क्योंकि logs किसी कहानी जैसे दिखते हैं। Investigator को approved action, outbound request और फिर एक gap दिखाई देता है। Gap किसी निष्कर्ष जैसा लगता है, लेकिन ऐसा नहीं है। वह ऐसा अंतराल है जिसमें कई महत्वपूर्ण अलग-अलग outcomes संभव हैं। सही response इस बात पर निर्भर करता है कि जिस तथ्य की आपको ज़रूरत है, उसका मालिक कौन-सा system है।

यहीं audit trail उपयोगी साबित होता है। उसे local system की जानकारी सुरक्षित रखनी चाहिए, यह साबित करना चाहिए कि सहेजे गए records चुपचाप बदले नहीं गए हैं और uncertainty को छिपाने के बजाय साफ़ दिखाना चाहिए। लेकिन वह खोए हुए response को इस बात का सबूत नहीं बना सकता कि database write, payment, deployment या remote command हुआ ही नहीं।

Timeout evidence gap है, पक्की failure नहीं

Timeout केवल यह बताता है कि किसी participant ने अपनी deadline से पहले usable response नहीं देखा। इससे यह पता नहीं चलता कि destination ने request पाई या नहीं, काम शुरू किया या नहीं, काम commit हुआ या नहीं, या लौटते समय response गायब हो गया।

Incident notes और agent actions दिखाने वाले किसी भी interface में इन outcomes को अलग रखें:

• Confirmed failure: Destination या local executor ने durable evidence लौटाया कि उसने requested operation को अस्वीकार या rollback किया।
• Confirmed success: बदली हुई state के मालिक system ने receipt लौटाई और follow-up read expected state की पुष्टि करता है।
• Unknown outcome: Action हुआ हो सकता है, लेकिन उपलब्ध evidence किसी एक निष्कर्ष तक नहीं पहुँचता।
• Not attempted: Gateway ने action को executor या transport तक पहुँचाने से पहले रोक दिया।

«Unknown» दरअसल «probably failed» कहने का संकोची तरीका नहीं है। यह अलग operational state है, जिसके लिए अलग playbook चाहिए। Automatic retries रोकें, evidence सुरक्षित रखें, authoritative system से पूछें और उसके बाद तय करें कि compensating action या retry सुरक्षित है या नहीं।

लोग अक्सर «partially successful» label भी बहुत जल्दी लगा देते हैं। इसका उपयोग तभी करें जब आप पूरी हुई और अधूरी sub-operation दोनों का नाम बता सकें। ऐसा deployment pipeline जिसने artifact बनाया लेकिन उसे promote नहीं किया, partial result है, बशर्ते दोनों तथ्य verify हों। Client द्वारा socket में bytes लिखने के बाद गायब हो गई request का result unknown है, चाहे request कितनी भी सरल क्यों न हो।

RFC 9110 protocol की भाषा में यही अंतर बताता है। Communication failure के बाद idempotent methods को automatically replay करने की अनुमति है, क्योंकि intended operation दोहराने पर intended effect वही रहता है। Non-idempotent request को अपने-आप retry करने से पहले client को यह स्थापित करना चाहिए कि original request लागू नहीं हुई, या application repeats को सुरक्षित बनाती है। यह semantic rule है, transport trick नहीं।

Agent action gateway को local facts सटीक रूप से बताने चाहिए। «Request sent; completion not observed» उपयोगी है। «Action failed» ऐसा दावा है जिसे local process करने का अधिकार शायद न रखता हो।

Power loss एक action को कई durability boundaries में बाँट देता है

Final result दिखने से पहले एक action कई boundaries पार कर सकता है। Testing से पहले इन्हें लिख लें। वरना केवल एक process crash करने वाला test झूठा confidence देगा।

एक सामान्य HTTP action में कम-से-कम ये boundaries होती हैं:

1. Gateway authorized intent स्वीकार करता है और उसे local रूप से record करता है।
2. Gateway authenticated request बनाकर transmission शुरू करता है।
3. Remote service request का इतना हिस्सा प्राप्त करती है कि processing शुरू कर सके।
4. Remote service अपना side effect commit करके receipt बनाती है।
5. Gateway response प्राप्त करके observed outcome record करता है।

SSH action का रास्ता मिलता-जुलता है, लेकिन remote host local client को exit status मिलने से पहले command शुरू कर सकता है। Host ऐसा काम भी fork कर सकता है जो session के बाद जारी रहे। सफल TCP या SSH connection से यह लगभग पता नहीं चलता कि command कहाँ रुकी।

Local writes की भी अपनी boundaries होती हैं। Process audit event append कर सकता है, operating system उसे cache में स्वीकार कर सकता है, filesystem metadata और data का क्रम तय कर सकता है और storage power loss के बाद bytes बचा सकता है। ये एक-दूसरे के समान घटनाएँ नहीं हैं।

POSIX fsync() specification के अनुसार call खुले file के queued data को storage device में भेजने का अनुरोध करती है और operation पूरा होने या error report होने तक return नहीं करती। उसका rationale यह भी चेताता है कि वास्तविक assurance implementation और storage configuration पर निर्भर करती है। यह caveat महत्वपूर्ण है: write call सफल लौटने भर से application power-loss safety नहीं मान सकती।

Investigation के लिए हर record को evidence class दें। हर timestamp को समान रूप से durable न मानें:

यह table जानबूझकर सख्त है। Process log की «sending request» line dispatch evidence है, delivery evidence नहीं। Memory में मौजूद response body observation evidence है। Durable local evidence तब तक नहीं है, जब तक आपकी persistence path उस failure model में सुरक्षित न रहे जिसे आप test करने का दावा करते हैं।

Failures test करने से पहले हर side effect को operation identity दें

अगर remote system के पास action पहचानने का स्थायी तरीका नहीं है, तो investigator interrupted action का reconciliation नहीं कर सकता। Chaos test लिखने से पहले operation identity जोड़ें, production में पहला duplicate दिखने के बाद नहीं।

जहाँ संभव हो, दो identifiers इस्तेमाल करें:

• Locally generated action ID, जो gateway के single attempt का नाम हो।
• Destination द्वारा पहचाना जाने वाला operation ID, idempotency key, request token, deployment ID या transaction reference।

इनमें एक ही random value हो सकती है, लेकिन यह न मानें कि दोनों का अर्थ एक ही है। Action ID local audit record की पहचान करती है। Remote identifier तभी उपयोगी होती है जब destination उसे side effect के साथ सहेजे और resulting state पाने का तरीका दे।

Idempotency keys वाली API में request के भीतर identity स्पष्ट रखें और meaningful payload का digest record करें। Digest से पता चल सकता है कि operator पुराने key को बदली हुई request के साथ गलती से reuse कर रहा है।

POST /v1/releases HTTP/1.1
Host: deploy.example.internal
Idempotency-Key: 8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1
Content-Type: application/json

{
  "operation_id": "8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1",
  "service": "catalog",
  "artifact": "sha256:3c1f...",
  "environment": "production"
}

Authorization header, bearer token या secrets वाली पूरी body log न करें। Method, destination identity, सुरक्षित request metadata, action ID, operation ID और payload digest record करें। Attempts की तुलना के लिए इतना evidence काफ़ी होना चाहिए, ताकि आपके audit system में दूसरा credential leak न बने।

एक उपयोगी intent record ऐसा हो सकता है:

{
  "event": "intent_accepted",
  "action_id": "act_01JX8F3Z6Z",
  "operation_id": "8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1",
  "channel": "http",
  "destination": "deploy.example.internal",
  "method": "POST",
  "path": "/v1/releases",
  "payload_sha256": "3c1f...",
  "authorization": "approved_for_session"
}

यह record investigation की एक आम गलती रोकता है। कोई व्यक्ति बाद के retry की तुलना केवल timestamp और endpoint से करता है, बदले हुए artifact या account को नहीं देखता और दो अलग operations को समान घोषित कर देता है।

SSH के लिए operation ID उस जगह रखें जहाँ remote host उसे सहेज सके। Shell command उसे structured logs में शामिल कर सकती है, deployment script उसे release record में लिख सकती है या remote wrapper duplicate ID अस्वीकार कर सकता है। केवल local SSH client transcript को proof न मानें।

ssh [email protected] \
  '/usr/local/bin/release --operation-id 8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1 --artifact sha256:3c1f...'

अगर command background worker शुरू करती है, तो worker को कुछ बदलने से पहले operation ID persist करनी चाहिए। वरना disconnect के बाद host काम करता रह सकता है और उस काम को खोजने का भरोसेमंद तरीका नहीं बचेगा।

उन boundaries पर interruption simulate करें जो decision बदलती हैं

अच्छा fault test process को उन points पर रोकता है जिनसे investigator के निर्णय अलग होते हैं। Loop में client को random तरीके से terminate करने से bugs मिल सकते हैं, लेकिन इससे यह नहीं समझ आता कि log का अर्थ क्या है।

ऐसा test destination बनाएँ जो नियंत्रित phases पर रुक सके और operation ID से reconciliation query का जवाब दे सके। इसे जटिल होने की ज़रूरत नहीं। इसे request received, side effect committed और response sent के बीच का अंतर दिखाना चाहिए।

इन पाँच cases से शुरुआत करें:

1. Intent persistence से पहले crash। Action durable local trail और destination, दोनों से गायब होना चाहिए। अगर destination बदला है, तो operations का क्रम गलत है या किसी दूसरे component ने action जारी किया।
2. Intent persistence के बाद, dispatch से पहले crash। Audit trail में accepted action दिखना चाहिए, dispatch record नहीं। इसे not attempted तभी कहें जब gateway साबित कर सके कि उसने action transport या executor को नहीं दिया।
3. Request transmission के दौरान crash। Destination को कुछ भी न मिला हो, partial request मिली हो या पूरी request मिली हो। Destination का निश्चित rejection या lookup result न हो तो इसे unknown रखें।
4. Remote commit के बाद, local completion persistence से पहले crash। Destination operation को completed दिखाए, लेकिन local trail में completion event न हो। यही test खतरनाक retry logic सामने लाता है।
5. Local completion persistence के बाद, agent को response मिलने से पहले crash। Local audit trail में answer मौजूद हो, भले agent को timeout लगा हो। नए agent session को action record query करना चाहिए, दूसरा operation blindly जारी नहीं करना चाहिए।

Local harness named pause files की मदद से gateway और test service को coordinate कर सकता है। Exact implementation अलग होगी, लेकिन test contract नहीं बदलना चाहिए। Interrupt करने से पहले harness को बताना चाहिए कि कौन-सी boundary पहुँची और reconciliation के लिए destination state बची रहनी चाहिए।

# Terminal 1: start the test destination with controlled pauses.
./test-api --pause-after=commit --state-file ./tmp/remote-state.json

# Terminal 2: run one authorized action with a known operation ID.
./gateway-test invoke \
  --operation-id 8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1 \
  --pause-file ./tmp/client-dispatch.pause

# When the destination reports "committed", terminate the local process.
kill -9 "$(pgrep -f 'gateway-test invoke')"

# Terminal 3: inspect the destination without issuing another mutation.
./test-api lookup 8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1

kill -9 process crash test करता है। यह hard power cut के दौरान storage behavior नहीं जाँचता और remote service द्वारा स्वीकार किए गए action को cancel नहीं करता। Outcome classification सीखते समय यही सीमा उपयोगी है। इससे team को caller की मृत्यु को callee के बारे में proof मानना बंद करना पड़ता है।

वास्तविक power-loss testing के लिए disposable machine या virtualized environment इस्तेमाल करें, जहाँ abrupt shutdown सुरक्षित रूप से दोहराया जा सके। ऐसे workstation की power cable न खींचें जिसमें production vault, audit material या working tree की एकमात्र copy हो। हर run के लिए exact build, storage mode, test inputs और time source सहेजें। इस context के बिना test result केवल एक anecdote है।

Audit trail को अपनी जानकारी और अपनी सीमाएँ दोनों बतानी चाहिए

अच्छा audit record स्पष्ट scope वाले claims की सूची जैसा पढ़ता है। वह उन systems के बारे में सर्वज्ञ सत्य का दिखावा नहीं करता जिन्हें वह देख नहीं सकता।

Interrupted action के लिए एक mutable status field overwrite करने के बजाय अलग-अलग events record करें। Append-only sequence बिना कोई final answer गढ़े स्थिति दिखा सकती है:

intent_accepted     action=act_01JX8F3Z6Z op=8b4d... principal=agent-process
transport_started   action=act_01JX8F3Z6Z channel=http
outcome_unobserved  action=act_01JX8F3Z6Z reason=local-process-terminated
reconciled_success  action=act_01JX8F3Z6Z receipt=rel_4921 source=remote-api

तीसरी line को remote_failed नहीं कहना चाहिए। वह केवल बताती है कि gateway terminal outcome observe नहीं कर सका। चौथी line बाद में उस source का claim जोड़ती है जिसके पास release state का अधिकार है।

यह अंतर tamper evidence को भी अधिक उपयोगी बनाता है। Hash chain सहेजे गए audit material में बदलाव दिखा सकती है, लेकिन जो event durable storage तक पहुँचा ही नहीं, उसे वापस नहीं ला सकती। अगर outbound call और log append के बीच machine की power चली जाए, तो intact chain action के result से पहले साफ़-साफ़ समाप्त हो सकती है। यह ज़रूरी नहीं कि chain टूटी हो। यह reconciliation की ज़रूरत वाला gap है।

Sallyport अपने Sessions और Activity journals को एक write-blind encrypted, hash-chained audit log से project करता है और sp audit verify ciphertext पर उस chain को offline जाँचता है। इससे investigator retained local history में बदलाव की जाँच कर सकता है, जबकि जहाँ ज़रूरी हो वहाँ remote outcome के लिए remote evidence पर निर्भर रह सकता है।

Authorization evidence को outcome evidence से अलग रखें। Approval यह दिखाती है कि किसी human या configured control ने action को आगे बढ़ने की अनुमति दी। इससे action के पूरा होने का पता नहीं चलता। इन claims को मिलाने पर approved लेकिन interrupted production change को झूठे तौर पर completed change बताया जा सकता है।

Timestamps पर भी यही चेतावनी लागू होती है। Wall-clock timestamps systems को correlate करने में मदद करते हैं, लेकिन machines के clocks अलग हों या buffers writes में देरी करें तो वे global order साबित नहीं करते। Order महत्वपूर्ण हो तो हर journal में sequence numbers, remote receipt IDs और reconciliation के दौरान service के अपने timestamps record करें।

Network calls को optimism नहीं, remote reconciliation चाहिए

जब HTTP call का response खो जाए, तो आमतौर पर destination ही यह बताने का authority रखता है कि requested state बदली या नहीं। Retry से पहले उससे पूछें और query इतनी specific रखें कि यह operation समान काम से अलग पहचाना जा सके।

सबसे सुरक्षित reconciliation order यह है:

1. Destination पर operation ID या idempotency key खोजें।
2. Completed operation मिले तो उसके resource IDs और payload digest को original intent से मिलाएँ।
3. Recorded rejection मिले तो उस response को failure evidence के रूप में सुरक्षित रखें।
4. Record न मिले तो retry से पहले देखें कि API delayed processing, asynchronous queues या eventual record creation की बात करती है या नहीं।
5. Retry तभी करें जब endpoint semantics और evidence repetition को सुरक्षित बनाते हों।

केवल safe method होने के कारण GET को harmless verification न मानें। कुछ APIs read endpoint के पीछे भी काम करती हैं और कुछ response caches write path से पीछे रहती हैं। Provider का contract जाँचें और संभव हो तो broad list को समय के आधार पर खोजने के बजाय specific created resource या operation record प्राप्त करें।

HTTP method labels मदद करते हैं, लेकिन application behavior तय नहीं करते। HTTP layer पर PUT idempotent हो सकती है, जबकि server हर receipt पर duplicate emails भेजे, usage charge करे या deployment hook चलाए। RFC 9110 स्पष्ट करता है कि idempotence requested effect पर लागू होती है; server अलग logs रख सकता है या अन्य side effects पैदा कर सकता है। इसलिए client library के verb से अधिक महत्वपूर्ण API owner द्वारा documented operation identity है।

«हर timeout को दो बार retry करें» लोकप्रिय लेकिन खराब सलाह है। कई timeouts transient होते हैं, इसलिए यह व्यावहारिक लगती है। लेकिन endpoint safely repeatable न हो तो यह transient transport issue को duplicate money movement, duplicate account creation या दो production releases में बदल देती है। Retry policy में operation type, idempotency mechanism, maximum delay और retry की अनुमति देने वाला evidence स्पष्ट होना चाहिए।

जिस remote service में lookup या idempotency support नहीं है, वहाँ ईमानदार उत्तर यह हो सकता है कि outcome automatically resolve नहीं किया जा सकता। इस सीमा के आसपास compensating process बनाएँ, जैसे exact request fingerprint वाला human review queue और प्रभावित state देखने वाला read-only account।

SSH commands के लिए remote host से proof चाहिए

Interrupted SSH session कई API calls से अधिक ambiguity छोड़ता है, क्योंकि client गायब होने के बाद भी command दूसरी ओर execute हो सकती है। खोया हुआ exit status failed command नहीं है। यह missing observation है।

ऐसी एक बड़ी shell line से बचें जो बिना checkpoints के कई mutations करती हो। Remote work को ऐसी operations में बाँटें जिनकी अपनी IDs और durable state हों। उदाहरण के लिए deployment wrapper एक operation ID के लिए received, validated, applied और completed दर्ज कर सकता है और read-only status command दे सकता है।

/usr/local/bin/release-status \
  --operation-id 8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1

Wrapper को non-repeatable action शुरू करने से पहले status लिखना चाहिए, बाद में नहीं। अगर वह cloud resource allocate, package publish या traffic switch करती है, तो provider receipt उसी operation ID के साथ सुरक्षित रखे। अगर ऐसा नहीं कर सकती, तो operation को remote queue के पीछे रखें जो यह काम कर सके।

Shell cleanup traps को recovery evidence मानने में सावधान रहें। Abrupt power loss के बाद local trap नहीं चलता। Forced kill के बाद remote trap भी न चले, और child process जारी रहते हुए चल सकता है। Cleanup logic गड़बड़ी कम कर सकती है, लेकिन final state साबित नहीं करती।

Remote marker तभी उपयोगी है जब उसका side effect से वास्तविक संबंध हो। /tmp/action-done में जोड़ी गई line यह साबित नहीं करती कि database migration commit हुई। उसी transaction में लिखा migration table entry बेहतर evidence है। Deployment controller द्वारा बनाया गया deployment record उससे भी बेहतर है।

Sallyport SSH को bundled stateless sp-ssh helper के जरिए route करता है, लेकिन नियम वही है: local action record यह बता सकता है कि gateway ने क्या attempt और observe किया। Unobserved remote outcome का निर्णय केवल remote host या command द्वारा बदले गए system के पास हो सकता है।

Investigator को एक interrupted release के पूरे रास्ते से गुज़ारें

मान लें कि agent HTTP endpoint के जरिए production release माँगता है। Gateway authorized intent को action ID act_01JX8F3Z6Z, operation ID 8b4d..., artifact digest 3c1f... और session approval के साथ record करता है। वह request शुरू करता है। Release service release commit करके receipt rel_4921 देती है। Response gateway तक पहुँचने से पहले laptop की power चली जाती है।

Restart के बाद agent transcript कहता है कि call timeout हो गई। Local audit trail transport_started पर समाप्त होता है। जो व्यक्ति इस line को failure का proof मानता है, वह fresh operation ID के साथ वही release फिर submit करता है। Service दूसरा release बना देती है। अगर release endpoint तुरंत activate होता है, तो दूसरा request केवल अनावश्यक हो सकता है। अगर वह irreversible migration शुरू करता है, तो नुकसान महँगा हो सकता है।

सही investigation act_01JX8F3Z6Z के automatic retry को रोककर शुरू होती है। Local audit chain verify करें। Last retained event, local process termination evidence, destination, payload digest और operation ID record करें। फिर release service से 8b4d... के बारे में पूछें।

तीन परिणाम उपयोगी हैं:

• Service artifact digest 3c1f... के साथ rel_4921 लौटाती है। Reconciliation के बाद original action को confirmed success मानें। Missing local completion audit gap है, release दोबारा भेजने का कारण नहीं।
• Service 8b4d... से जुड़ी durable rejection लौटाती है। इसे confirmed failure मानें। Corrected request पर निर्णय लेने से पहले rejection reason सुरक्षित रखें।
• Service कोई record नहीं लौटाती। जाँचें कि क्या वह operation records बनाने से पहले requests queue करती है और query path में lag है। अगर delayed work को खारिज नहीं किया जा सकता, तो unknown outcome बनाए रखें और blind retry के बजाय escalate करें।

ध्यान दें कि case का निर्णय किन बातों से नहीं होता: agent का timeout, gateway process का exit या human approval। ये तथ्य महत्वपूर्ण हैं, लेकिन release state का मालिक इनमें से कोई नहीं है।

यह walkthrough एक design requirement भी दिखाता है। अगर destination operation ID से search नहीं कर सकती, तो gateway को या तो उस destination के विरुद्ध unattended non-repeatable actions से बचना होगा या human reconciliation path आवश्यक करना होगा। Audit quality उस API की कमी पूरी नहीं कर सकती जो अपने side effects पहचानने का durable तरीका ही न दे।

Retry rules इतने सीमित हों कि कठिन समय में भी काम करें

Retry policy में केवल «network errors पर retry करें» नहीं होना चाहिए। उसे ऐसी decision table में लिखें जिसका पालन implementer और incident responder दोनों कर सकें।

Recovery के दौरान agents को नया operation ID बनाने न दें। यह duplicate पैदा करने का सूक्ष्म तरीका है। Retry valid हो तो वही destination-recognized identity reuse करें और साबित करें कि retry payload original intent से मेल खाता है। Desired change बदल गया हो तो वह नया action है और उसे नई authorization decision चाहिए।

Unresolved actions के लिए terminal state रखें। «Unknown, awaiting reconciliation» उस job से बेहतर है जो हमेशा retry करती रहे, क्योंकि state machine में uncertainty के लिए state ही नहीं बनाई गई। इस state का owner, deadline और escalation path तय करें। वरना पुराना ambiguous action कई सप्ताह बाद अधूरे remote logs के साथ फिर सामने आ सकता है।

Systems के answer भूलने से पहले evidence सुरक्षित करें

Interruption के बाद पहला घंटा महत्वपूर्ण होता है। उस समय remote services में request traces, queue entries और operator context अभी मौजूद होते हैं। Log retention, cache eviction या किसी दूसरे deployment से पहले facts capture करें।

Local audit material को original form में सुरक्षित रखें और ticket में excerpts copy करने से पहले verify करें। Exact action ID, operation ID, destination, payload digest, authorization record, last local event और local restart time record करें। फिर remote operation record, resource revision, provider request ID और answer के लिए इस्तेमाल किए गए service time source को लें।

Fake completion event जोड़कर history repair न करें। बाद का reconciliation event जोड़ें, जिसमें उसका source और evidence लिखा हो। Investigators को original boundary दिखनी चाहिए, क्योंकि boundary बताती है कि उस समय system क्या जानता था।

स्थायी सीख असुविधाजनक लेकिन सरल है: audited action अच्छी तरह authorized और carefully logged हो सकती है, फिर भी power loss के बाद उसका remote result unknown रह सकता है। Autonomous agent को ऐसा काम देने से पहले action identities, remote receipts और reconciliation paths बनाएँ जिसे दो बार सुरक्षित रूप से नहीं किया जा सकता। जब गलत समय पर lights चली जाती हैं, तब यही choices तय करती हैं कि आपकी team केवल एक gap की जाँच करेगी या दूसरा incident पैदा कर देगी।