समस्या निवारण: वर्कफ़्लो

"Workflow not found or not accessible"

वर्कफ़्लो मौजूद है लेकिन आपके वर्तमान सत्र taint से उच्च वर्गीकरण स्तर पर संग्रहीत है।

CONFIDENTIAL सत्र के दौरान सहेजे गए वर्कफ़्लो PUBLIC या INTERNAL सत्रों में अदृश्य हैं। स्टोर हर लोड पर canFlowTo जाँच का उपयोग करता है, और जब वर्कफ़्लो का वर्गीकरण सत्र taint से अधिक होता है तो null (जो "नहीं मिला" के रूप में दिखता है) लौटाता है।

समाधान: पहले वर्गीकृत डेटा एक्सेस करके अपने सत्र taint को बढ़ाएँ, या यदि सामग्री अनुमति देती है तो निम्न-वर्गीकरण सत्र से वर्कफ़्लो को पुनः सहेजें।

सत्यापन: workflow_list चलाएँ यह देखने के लिए कि आपके वर्तमान वर्गीकरण स्तर पर कौन से वर्कफ़्लो दिखाई दे रहे हैं। यदि अपेक्षित वर्कफ़्लो गायब है, तो यह उच्च स्तर पर सहेजा गया था।

---

"Workflow classification ceiling breached"

सत्र का taint स्तर वर्कफ़्लो के classification_ceiling से अधिक हो गया है। यह जाँच हर कार्य से पहले चलती है, इसलिए यदि पहले का कोई कार्य सत्र taint को बढ़ाता है तो यह निष्पादन के बीच में ट्रिगर हो सकता है।

उदाहरण के लिए, classification_ceiling: INTERNAL वाला वर्कफ़्लो रुक जाएगा यदि triggerfish:memory कॉल CONFIDENTIAL डेटा प्राप्त करता है जो सत्र taint को बढ़ाता है।

समाधान:

• अपेक्षित डेटा संवेदनशीलता से मेल खाने के लिए वर्कफ़्लो का classification_ceiling बढ़ाएँ।
• या वर्कफ़्लो को पुनर्गठित करें ताकि वर्गीकृत डेटा एक्सेस न हो। वर्गीकृत मेमोरी पढ़ने के बजाय इनपुट पैरामीटर का उपयोग करें।

---

YAML पार्स त्रुटियाँ

"YAML parse error: ..."

सामान्य YAML सिंटैक्स गलतियाँ:

इंडेंटेशन। YAML व्हाइटस्पेस-संवेदनशील है। टैब नहीं, स्पेस का उपयोग करें। प्रत्येक नेस्टिंग स्तर बिल्कुल 2 स्पेस होना चाहिए।

# Wrong — tabs or inconsistent indent
do:
- fetch:
      call: http

# Correct
do:
  - fetch:
      call: http

अभिव्यक्तियों के चारों ओर उद्धरण चिह्न गायब। ${ } वाली अभिव्यक्ति स्ट्रिंग को उद्धृत किया जाना चाहिए, अन्यथा YAML { को इनलाइन मैपिंग के रूप में व्याख्या करता है।

# Wrong — YAML parse error
endpoint: ${ .config.url }

# Correct
endpoint: "${ .config.url }"

document ब्लॉक गायब। प्रत्येक वर्कफ़्लो में dsl, namespace और name के साथ एक document फ़ील्ड होना चाहिए:

document:
  dsl: "1.0"
  namespace: my-workflows
  name: my-workflow

"Workflow YAML must be an object"

YAML सफलतापूर्वक पार्स हुआ लेकिन परिणाम एक स्केलर या ऐरे है, ऑब्जेक्ट नहीं। जाँचें कि आपके YAML में शीर्ष-स्तरीय कुंजियाँ (document, do) हैं।

"Task has no recognized type"

प्रत्येक कार्य प्रविष्टि में बिल्कुल एक प्रकार कुंजी होनी चाहिए: call, run, set, switch, for, raise, emit, या wait। यदि पार्सर इनमें से कोई कुंजी नहीं पाता, तो यह अपरिचित प्रकार की रिपोर्ट करता है।

सामान्य कारण: कार्य प्रकार नाम में टाइपो (उदा., call के बजाय calls)।

---

अभिव्यक्ति मूल्यांकन विफलताएँ

गलत या खाली मान

अभिव्यक्तियाँ ${ .path.to.value } सिंटैक्स का उपयोग करती हैं। अग्रणी डॉट आवश्यक है — यह पथ को वर्कफ़्लो के डेटा संदर्भ रूट पर एंकर करता है।

# Wrong — missing leading dot
value: "${ result.name }"

# Correct
value: "${ .result.name }"

आउटपुट में "undefined"

डॉट-पथ ने कुछ भी हल नहीं किया। सामान्य कारण:

• गलत कार्य नाम। प्रत्येक कार्य अपने नाम के अंतर्गत अपना परिणाम संग्रहीत करता है। यदि आपका कार्य fetch_data नाम का है, तो इसके परिणाम को ${ .fetch_data } के रूप में संदर्भित करें, ${ .data } या ${ .result } नहीं।
• गलत नेस्टिंग। यदि HTTP कॉल {"data": {"items": [...]}} लौटाता है, तो आइटम ${ .fetch_data.data.items } पर हैं।
• ऐरे इंडेक्सिंग। ब्रैकेट सिंटैक्स का उपयोग करें: ${ .items[0].name }। केवल-डॉट पथ संख्यात्मक इंडेक्स का समर्थन नहीं करते।

बूलियन शर्तें काम नहीं कर रहीं

अभिव्यक्ति तुलनाएँ सख्त हैं (===)। सुनिश्चित करें कि प्रकार मेल खाते हैं:

# This fails if .count is a string "0"
if: "${ .count == 0 }"

# Works when .count is a number
if: "${ .count == 0 }"

जाँचें कि अपस्ट्रीम कार्य स्ट्रिंग या संख्या लौटाते हैं। HTTP प्रतिक्रियाएँ अक्सर स्ट्रिंग मान लौटाती हैं जिन्हें तुलना के लिए रूपांतरण की आवश्यकता नहीं होती — बस स्ट्रिंग रूप से तुलना करें।

---

HTTP कॉल विफलताएँ

टाइमआउट

HTTP कॉल web_fetch टूल के माध्यम से जाते हैं। यदि लक्ष्य सर्वर धीमा है, तो अनुरोध समय सीमा समाप्त हो सकती है। वर्कफ़्लो DSL में HTTP कॉल के लिए कोई प्रति-कार्य टाइमआउट ओवरराइड नहीं है — web_fetch टूल का डिफ़ॉल्ट टाइमआउट लागू होता है।

SSRF ब्लॉक

Triggerfish में सभी आउटबाउंड HTTP पहले DNS हल करता है और हल किए गए IP को हार्डकोडेड अस्वीकृति सूची से जाँचता है। निजी और आरक्षित IP श्रेणियाँ हमेशा अवरुद्ध होती हैं।

यदि आपका वर्कफ़्लो निजी IP पर आंतरिक सेवा को कॉल करता है (उदा., http://192.168.1.100/api), तो इसे SSRF रोकथाम द्वारा अवरुद्ध किया जाएगा। यह जानबूझकर है और कॉन्फ़िगर नहीं किया जा सकता।

समाधान: सार्वजनिक IP पर हल होने वाले सार्वजनिक होस्टनाम का उपयोग करें, या सीधी पहुँच वाले MCP सर्वर के माध्यम से रूट करने के लिए triggerfish:mcp का उपयोग करें।

हेडर गायब

http कॉल प्रकार with.headers को सीधे अनुरोध हेडर में मैप करता है। यदि आपके API को प्रमाणीकरण की आवश्यकता है, तो हेडर शामिल करें:

- fetch:
    call: http
    with:
      endpoint: "https://api.example.com/data"
      headers:
        Authorization: "Bearer ${ .api_token }"

सुनिश्चित करें कि टोकन मान वर्कफ़्लो इनपुट में प्रदान किया गया है या पूर्व कार्य द्वारा सेट किया गया है।

---

उप-वर्कफ़्लो पुनरावर्तन सीमा

"Workflow recursion depth exceeded maximum of 5"

उप-वर्कफ़्लो 5 स्तर गहरे तक नेस्ट हो सकते हैं। यह सीमा अनंत पुनरावर्तन को रोकती है जब वर्कफ़्लो A वर्कफ़्लो B को कॉल करता है जो वर्कफ़्लो A को कॉल करता है।

समाधान:

• वर्कफ़्लो श्रृंखला को समतल करें। चरणों को कम वर्कफ़्लो में संयोजित करें।
• जाँचें कि क्या दो वर्कफ़्लो एक दूसरे को कॉल करने वाले चक्रीय संदर्भ हैं।

---

शेल निष्पादन अक्षम

"Shell execution failed" या run कार्यों से खाली परिणाम

वर्कफ़्लो टूल संदर्भ में allowShellExecution फ़्लैग नियंत्रित करता है कि shell या script लक्ष्य वाले run कार्यों की अनुमति है या नहीं। अक्षम होने पर, ये कार्य विफल हो जाते हैं।

समाधान: जाँचें कि आपके Triggerfish कॉन्फ़िगरेशन में शेल निष्पादन सक्षम है या नहीं। उत्पादन वातावरण में, सुरक्षा के लिए शेल निष्पादन जानबूझकर अक्षम किया जा सकता है।

---

वर्कफ़्लो चलता है लेकिन गलत आउटपुट देता है

workflow_history से डिबगिंग

पिछले रन की जाँच के लिए workflow_history का उपयोग करें:

workflow_history with workflow_name: "my-workflow" and limit: "5"

प्रत्येक इतिहास प्रविष्टि में शामिल है:

• status — completed या failed
• error — विफल होने पर त्रुटि संदेश
• taskCount — वर्कफ़्लो में कार्यों की संख्या
• startedAt / completedAt — समय की जानकारी

संदर्भ प्रवाह की जाँच

प्रत्येक कार्य अपने नाम के अंतर्गत डेटा संदर्भ में अपना परिणाम संग्रहीत करता है। यदि आपके वर्कफ़्लो में fetch, transform और save नाम के कार्य हैं, तो तीनों कार्यों के बाद डेटा संदर्भ इस प्रकार दिखता है:

{
  "fetch": { "...http response..." },
  "transform": { "...transformed data..." },
  "save": { "...save result..." }
}

सामान्य गलतियाँ:

• संदर्भ ओवरराइटिंग। पहले से मौजूद कुंजी को असाइन करने वाला set कार्य पिछले मान को बदल देगा।
• गलत कार्य संदर्भ। कार्य का नाम step_1 होने पर ${ .step1 } को संदर्भित करना।
• इनपुट ट्रांसफ़ॉर्म संदर्भ बदलता है। input.from निर्देश कार्य के इनपुट संदर्भ को पूरी तरह बदल देता है। यदि आप input.from: "${ .config }" का उपयोग करते हैं, तो कार्य केवल config ऑब्जेक्ट देखता है, पूर्ण संदर्भ नहीं।

गायब आउटपुट

यदि वर्कफ़्लो पूर्ण हो जाता है लेकिन खाली आउटपुट लौटाता है, तो जाँचें कि अंतिम कार्य का परिणाम वह है जो आप अपेक्षा करते हैं। वर्कफ़्लो आउटपुट पूर्णता पर पूर्ण डेटा संदर्भ है, आंतरिक कुंजियाँ फ़िल्टर की गई हैं।

---

workflow_delete पर "Permission denied"

workflow_delete टूल सत्र के वर्तमान taint स्तर का उपयोग करके पहले वर्कफ़्लो लोड करता है। यदि वर्कफ़्लो आपके सत्र taint से अधिक वर्गीकरण स्तर पर सहेजा गया था, तो लोड null लौटाता है और workflow_delete "permission denied" के बजाय "not found" की रिपोर्ट करता है।

यह जानबूझकर है — वर्गीकृत वर्कफ़्लो का अस्तित्व निम्न-वर्गीकरण सत्रों को प्रकट नहीं किया जाता।

समाधान: हटाने से पहले अपने सत्र taint को वर्कफ़्लो के वर्गीकरण स्तर से मेल खाने या उससे अधिक करने के लिए बढ़ाएँ। या उसी सत्र प्रकार से हटाएँ जहाँ यह मूल रूप से सहेजा गया था।

---

स्व-उपचार

"Step metadata missing on task 'X': self-healing requires description, expects, produces"

जब self_healing.enabled true है, तो हर कार्य में तीनों metadata फ़ील्ड होने चाहिए। यदि कोई भी गायब है तो पार्सर सहेजते समय वर्कफ़्लो को अस्वीकार करता है।

समाधान: हर कार्य के metadata ब्लॉक में description, expects, और produces जोड़ें:

- my-task:
    call: http
    with:
      endpoint: "https://example.com/api"
    metadata:
      description: "What this step does and why"
      expects: "What this step needs as input"
      produces: "What this step outputs"

---

"Self-healing config mutation rejected in version proposal"

उपचार एजेंट ने एक नया वर्कफ़्लो संस्करण प्रस्तावित किया जो self_healing कॉन्फ़िग ब्लॉक को संशोधित करता है। यह निषिद्ध है — एजेंट अपने स्वयं के उपचार कॉन्फ़िगरेशन को नहीं बदल सकता।

यह अपेक्षित व्यवहार है। केवल मानव ही workflow_save के माध्यम से सीधे वर्कफ़्लो का नया संस्करण सहेजकर self_healing कॉन्फ़िग को संशोधित कर सकते हैं।

---

उपचार एजेंट उत्पन्न नहीं हो रहा

वर्कफ़्लो चलता है लेकिन कोई उपचार एजेंट प्रकट नहीं होता। जाँचें:

1. enabled true है metadata.triggerfish.self_healing में।
2. कॉन्फ़िग सही स्थान पर है — metadata.triggerfish.self_healing के अंतर्गत नेस्टेड होना चाहिए, शीर्ष स्तर पर नहीं।
3. सभी चरणों में metadata है — यदि सहेजते समय सत्यापन विफल होता है, तो वर्कफ़्लो स्व-उपचार सक्षम किए बिना सहेजा गया था।

---

प्रस्तावित सुधार लंबित में अटके हुए

यदि approval_required true है (डिफ़ॉल्ट), तो प्रस्तावित संस्करण मानव समीक्षा की प्रतीक्षा करते हैं। लंबित प्रस्ताव देखने के लिए workflow_version_list का उपयोग करें और उन पर कार्रवाई करने के लिए workflow_version_approve या workflow_version_reject का उपयोग करें।

---

"Retry budget exhausted" / अनसुलझे आगे बढ़ाना

उपचार एजेंट ने समस्या को हल किए बिना अपने सभी हस्तक्षेप प्रयास (डिफ़ॉल्ट 3) उपयोग कर लिए हैं। यह unresolvable के रूप में आगे बढ़ाता है और सुधार प्रयास बंद कर देता है।

समाधान:

• कौन से हस्तक्षेप आज़माए गए यह देखने के लिए workflow_healing_status जाँचें।
• अंतर्निहित समस्या की समीक्षा करें और मैन्युअल रूप से ठीक करें।
• अधिक प्रयासों की अनुमति देने के लिए, स्व-उपचार कॉन्फ़िग में retry_budget बढ़ाएँ और वर्कफ़्लो को पुनः सहेजें।