कमांड कतार

​

क्यों

• ऑटो-रिप्लाई रन महँगे हो सकते हैं (LLM कॉल) और जब एकाधिक इनबाउंड संदेश लगभग एक साथ आते हैं, तो वे टकरा सकते हैं।
• क्रमबद्ध करने से साझा संसाधनों (सत्र फ़ाइलें, लॉग, CLI stdin) के लिए प्रतिस्पर्धा से बचा जाता है और अपस्ट्रीम दर सीमाएँ लागू होने की संभावना कम होती है।

​

यह कैसे काम करता है

• एक लेन-जागरूक FIFO कतार प्रत्येक लेन को कॉन्फ़िगर करने योग्य समवर्ती सीमा के साथ खाली करती है (बिना कॉन्फ़िगरेशन वाली लेन के लिए डिफ़ॉल्ट 1; main का डिफ़ॉल्ट 4 और subagent का 8 है)।
• runEmbeddedAgent सत्र कुंजी (लेन session:<key>) के आधार पर कतारबद्ध करता है, ताकि प्रत्येक सत्र के लिए केवल एक सक्रिय रन की गारंटी रहे।
• इसके बाद प्रत्येक सत्र रन को एक ग्लोबल लेन (डिफ़ॉल्ट रूप से main) में कतारबद्ध किया जाता है, ताकि समग्र समानांतरता agents.defaults.maxConcurrent द्वारा सीमित रहे।
• वर्बोज़ लॉगिंग सक्षम होने पर, कतारबद्ध रन शुरू होने से पहले ~2s से अधिक प्रतीक्षा करने पर एक छोटी सूचना उत्सर्जित करते हैं।
• कतारबद्ध होते ही टाइपिंग संकेतक अब भी तुरंत सक्रिय होते हैं (जब चैनल उनका समर्थन करता है), इसलिए रन के अपनी बारी की प्रतीक्षा करने के दौरान उपयोगकर्ता अनुभव अपरिवर्तित रहता है।

​

डिफ़ॉल्ट

• mode: "steer"
• debounceMs: 500
• cap: 20
• drop: "summarize"

​

कतार मोड

• steer: संदेशों को सक्रिय रनटाइम में इंजेक्ट करें। OpenClaw सभी लंबित स्टीयरिंग संदेशों को वर्तमान असिस्टेंट टर्न के अपने टूल कॉल निष्पादित करने के बाद, अगले LLM कॉल से पहले डिलीवर करता है; Codex app-server को एक बैच किया हुआ turn/steer प्राप्त होता है। यदि रन सक्रिय रूप से स्ट्रीम नहीं कर रहा है या स्टीयरिंग उपलब्ध नहीं है, तो OpenClaw प्रॉम्प्ट शुरू करने से पहले सक्रिय रन के समाप्त होने की प्रतीक्षा करता है।
• followup: स्टीयर न करें। वर्तमान रन समाप्त होने के बाद प्रत्येक संदेश को बाद के एजेंट टर्न के लिए कतारबद्ध करें।
• collect: स्टीयर न करें। शांत अवधि के बाद कतारबद्ध संदेशों को एकल फ़ॉलोअप टर्न में संयोजित करें। यदि संदेश अलग-अलग चैनल/थ्रेड को लक्षित करते हैं, तो रूटिंग बनाए रखने के लिए वे अलग-अलग खाली किए जाते हैं।
• interrupt: उस सत्र के सक्रिय रन को निरस्त करें, फिर नवीनतम संदेश चलाएँ।

{
  messages: {
    queue: {
      mode: "steer",
      debounceMs: 500,
      cap: 20,
      drop: "summarize",
      byChannel: { discord: "collect" },
    },
  },
}

​

कतार विकल्प

• debounceMs: कतारबद्ध फ़ॉलोअप या कलेक्ट बैच खाली करने से पहले की शांत अवधि; Codex steer मोड में, बैच किया हुआ turn/steer भेजने से पहले की शांत अवधि। बिना इकाई वाली संख्याएँ मिलीसेकंड होती हैं; /queue विकल्पों द्वारा ms, s, m, h, और d इकाइयाँ स्वीकार की जाती हैं।
• cap: प्रति सत्र कतारबद्ध संदेशों की अधिकतम संख्या। 1 से कम मानों को अनदेखा किया जाता है।
• drop: "summarize" (डिफ़ॉल्ट): आवश्यकतानुसार सबसे पुरानी कतारबद्ध प्रविष्टियाँ हटाएँ, संक्षिप्त सारांश बनाए रखें और उन्हें सिंथेटिक फ़ॉलोअप प्रॉम्प्ट के रूप में इंजेक्ट करें।
• drop: "old": सारांश संरक्षित किए बिना, आवश्यकतानुसार सबसे पुरानी कतारबद्ध प्रविष्टियाँ हटाएँ।
• drop: "new": कतार पहले से भरी होने पर नवीनतम संदेश अस्वीकार करें।

​

स्टीयरिंग और स्ट्रीमिंग

• partial: पूर्वावलोकन जल्दी अंतिम रूप ले सकता है, फिर स्टीयरिंग स्वीकार होने के बाद नया पूर्वावलोकन शुरू होता है।
• block: ड्राफ़्ट-आकार के ब्लॉक वही क्रमिक स्वरूप बना सकते हैं।
• स्ट्रीमिंग के बिना, जब रनटाइम उसी टर्न में स्टीयरिंग स्वीकार नहीं कर सकता, तो सक्रिय रन के बाद स्टीयरिंग फ़ॉलोअप के रूप में फ़ॉलबैक करती है।

​

प्राथमिकता क्रम

1. इनलाइन या संग्रहीत प्रति-सत्र /queue ओवरराइड।
2. messages.queue.byChannel.<channel>।
3. messages.queue.mode।
4. डिफ़ॉल्ट steer।

​

प्रति-सत्र ओवरराइड

• वर्तमान सत्र के लिए कतार मोड संग्रहीत करने हेतु /queue <steer|followup|collect|interrupt> को एक स्वतंत्र कमांड के रूप में भेजें।
• विकल्पों को संयोजित किया जा सकता है: /queue collect debounce:0.5s cap:25 drop:summarize
• /queue default या /queue reset सत्र ओवरराइड साफ़ करता है।

​

कतारबद्ध टर्न निरस्तीकरण

• किसी विशिष्ट runId के साथ chat.abort, उस टर्न के अब भी कतारबद्ध रहने के दौरान उसे निरस्त करता है, बशर्ते अनुरोधकर्ता अधिकृत हो (सक्रिय रन के समान स्वामित्व नियम)।
• बिना runId वाले सत्र के लिए chat.abort पहले अधिकृत कतारबद्ध टर्न निरस्त करता है, फिर अधिकृत सक्रिय रन निरस्त करता है। यह क्रम कतार खाली होने पर कार्य को आधे-अधूरे रुके हुए सत्र में आगे बढ़ने से रोकता है।
• प्रति-अनुरोधकर्ता जाँच के बिना पूरी सत्र कतार साफ़ करना बहु-स्वामी सत्रों के लिए स्टॉप पथ नहीं है।
• कतारबद्ध प्रतीक्षाएँ sessions.list के लिए सक्रिय एजेंट रन के रूप में प्रक्षेपित नहीं होतीं और सक्रिय-रन टाइमआउट अर्थविज्ञान की स्वामी नहीं होतीं; केवल सक्रिय चरण इसका स्वामी होता है।

​

दायरा और गारंटियाँ

• यह गेटवे रिप्लाई पाइपलाइन का उपयोग करने वाले सभी इनबाउंड चैनलों (WhatsApp वेब, Telegram, Slack, Discord, Signal, iMessage, वेबचैट आदि) के ऑटो-रिप्लाई एजेंट रन पर लागू होता है।
• डिफ़ॉल्ट लेन (main) इनबाउंड + मुख्य Heartbeat के लिए पूरी प्रक्रिया में साझा होती है; एकाधिक सत्रों को समानांतर चलने देने के लिए agents.defaults.maxConcurrent सेट करें।
• अतिरिक्त लेन मौजूद हो सकती हैं (जैसे cron, cron-nested, nested, subagent), ताकि बैकग्राउंड जॉब इनबाउंड उत्तरों को अवरुद्ध किए बिना समानांतर चल सकें। पृथक Cron एजेंट टर्न एक cron स्लॉट बनाए रखते हैं, जबकि उनका आंतरिक एजेंट निष्पादन cron-nested का उपयोग करता है। साझा गैर-Cron nested प्रवाह अपना लेन व्यवहार बनाए रखते हैं। इन अलग किए गए रन को बैकग्राउंड टास्क के रूप में ट्रैक किया जाता है।
• प्रति-सत्र लेन गारंटी देती हैं कि एक समय में केवल एक एजेंट रन किसी दिए गए सत्र को प्रभावित करे।
• कोई बाहरी निर्भरता या बैकग्राउंड वर्कर थ्रेड नहीं; केवल TypeScript + प्रॉमिस।

​

समस्या निवारण

• यदि कमांड अटके हुए लगते हैं, तो वर्बोज़ लॉग सक्षम करें और यह पुष्टि करने के लिए “queued for …ms” पंक्तियाँ खोजें कि कतार खाली हो रही है।
• जो Codex app-server रन किसी टर्न को स्वीकार करने के बाद प्रगति उत्सर्जित करना बंद कर देते हैं, उन्हें Codex अडैप्टर बाधित करता है, ताकि सक्रिय सत्र लेन बाहरी रन टाइमआउट की प्रतीक्षा करने के बजाय रिलीज़ हो सके।
• डायग्नोस्टिक्स सक्षम होने पर, वे सत्र जो बिना किसी देखे गए उत्तर, टूल, स्थिति, ब्लॉक या ACP प्रगति के अंतर्निहित चेतावनी सीमा से आगे processing में बने रहते हैं, उन्हें वर्तमान गतिविधि के आधार पर वर्गीकृत किया जाता है:
  • हाल की प्रगति वाला सक्रिय कार्य session.long_running के रूप में लॉग होता है। स्वामित्व वाली मौन मॉडल कॉल भी अंतर्निहित निरस्तीकरण सीमा तक session.long_running बनी रहती हैं, ताकि धीमे या गैर-स्ट्रीमिंग प्रदाताओं को बहुत जल्दी रुका हुआ न बताया जाए।
  • हाल की प्रगति के बिना सक्रिय कार्य session.stalled के रूप में लॉग होता है; स्वामित्व वाली मॉडल कॉल, अवरुद्ध टूल कॉल और रुके हुए एम्बेडेड रन निरस्तीकरण सीमा पर या उसके बाद session.stalled में बदल जाते हैं। स्वामी-विहीन पुरानी मॉडल/टूल गतिविधि को लंबे समय से चल रही गतिविधि के रूप में छिपाया नहीं जाता।
  • session.stuck पुनर्प्राप्त करने योग्य पुराने सत्र बहीखाते के लिए आरक्षित है, जिसमें पुरानी स्वामी-विहीन मॉडल/टूल गतिविधि वाले निष्क्रिय कतारबद्ध सत्र शामिल हैं।
  • session.stuck हमेशा ऐसी पुनर्प्राप्ति ट्रिगर करता है, जो प्रभावित सत्र लेन को रिलीज़ कर सकती है। निरस्तीकरण सीमा पार कर चुका session.stalled वर्गीकरण (अवरुद्ध टूल कॉल, रुकी हुई मॉडल कॉल या रुका हुआ एम्बेडेड रन) भी सक्रिय-निरस्तीकरण पुनर्प्राप्ति ट्रिगर कर सकता है, इसलिए केवल session.stuck ही नहीं, दोनों वर्गीकरण कतार को फिर से चला सकते हैं।
  • सत्र के अपरिवर्तित रहने के दौरान बार-बार आने वाली session.stuck और session.long_running चेतावनी लॉग पंक्तियाँ घातांकीय रूप से पीछे हटती हैं; उस बैकऑफ़ के बावजूद प्रत्येक Heartbeat टिक पर पुनर्प्राप्ति प्रयास चलते रहते हैं।

​

संबंधित

• सत्र प्रबंधन
• स्टीयरिंग कतार
• स्टीयर करें
• पुनः प्रयास नीति