ابدأ بالجزء الذي يلي الخطأ
فصّل الأعراض قبل حذف السجل
thread not found
خطأ في مرجع التخزين (غالبًا ما يبقى السجل قابلًا للقراءة)
Timeout / App server request expired while queued
المحتويات
- 1. ما الذي لا يُعثر عليه في «thread not found»؟
- 2. مثال عملي: استعادة الإرسال مع بقاء السجل كما هو
- 3. ترتيب المحاولات عند فشل الإرسال وحده
- 4. الرسالة نفسها لا تعني سببًا واحدًا ولا حلًا واحدًا
- 5. عند استمرار المشكلة: الفحوص والتسليم
- 6. المعلومات الواجب تضمينها عند طلب فحص المشكلة
- 7. تأكّد من الاستعادة برد قصير
- الأسئلة الشائعة
1. ما الذي لا يُعثر عليه في «thread not found»؟
عند إرسال رسالة متابعة إلى مهمة موجودة في Codex من OpenAI، قد يظهر خطأ مثل الآتي. المعرّف في آخر السطر يحدد المحادثة المستهدفة، وقد أخفيناه فيما يلي.
メッセージの送信中にエラーが発生しました
thread not found: <معرّف المحادثة>في التطبيقات المعروضة بالإنجليزية، يكون السطر الأول Error submitting message (#30710).
Error submitting message
thread not found: <معرّف المحادثة>تتناول هذه المقالة المهام المحلية الموجودة في تطبيق سطح المكتب. وهي مبنية على سجلات من مثال واجهناه في بيئتنا (Windows)، والشيفرة المصدرية العامة، وتقارير المستخدمين عن الأعطال، وتعكس الوضع حتى 21 سبتمبر 2026.
«القدرة على القراءة» و«القدرة على الإرسال» فحصان منفصلان
السجل المحفوظ
قراءة المحادثات السابقة
استرجاع البيانات المحفوظة
المحادثة المحمّلة للتنفيذ
استقبال التعليمات الجديدة
استئناف المحادثة → التعليمة التالية
إذا تعذّر العثور على المحادثة الخاصة بالتنفيذ، فقد يفشل الإرسال حتى إذا أمكن عرض السجل السابق.
عرض السجل وقبول التعليمات الجديدة آليتان منفصلتان. بالنسبة إلى مهمة لم تستخدمها منذ فترة، قد يُحمَّل السجل بينما لا تكون المحادثة محمّلة في الجانب الذي يقبل التعليمات. عندها يؤدي الإرسال كما هو إلى هذا الخطأ.
تفاصيل الآلية (أسماء الاتصال الداخلي للتطبيق)
وفق مواصفات App Server الرسمية، فإن thread/read عملية لقراءة السجل المحفوظ، وليست عملية تحميل المحادثة في ذاكرة التنفيذ. ودوره يختلف عن دور thread/resume الذي يستأنف المحادثة. وهذه أسماء اتصال داخلية للتطبيق، وليست أوامر تكتبها في مربع الدردشة.
وفي الشيفرة المصدرية العامة لمعالجة الإرسال المقابلة لإصدار CLI 0.155.0-alpha.9 الموجود في البيانات الوصفية المحفوظة في بيئتنا، فإن نقطة دخول turn/start تجلب المحادثة، وإذا فشل ذلك تُعيد thread not found. ومصدر الجلب هو قائمة المحادثات في الذاكرة، لذا لا يعني هذا الخطأ فقدان ملف الحفظ.
notLoaded هي الحالة الطبيعية التي تكون فيها المحادثة المحفوظة غير محمّلة حاليًا للتنفيذ. وفق المواصفات الرسمية لـ App Server، يُلغى تحميل المحادثة التي غادرها آخر مشترك وتتحول إلى notLoaded بعد مرور 30 دقيقة دون مشتركين ودون نشاط. المشكلة هي أن إجراء الاستئناف اللازم لا يحدث من هذه الحالة، فلا تُقبل التعليمة التالية. وفي مثالنا أيضًا، حدث الفشل بعد أكثر من ساعة من آخر إرسال ناجح.
2. مثال عملي: استعادة الإرسال مع بقاء السجل كما هو
هذا مثال من بيئتنا. ظهر هذا الخطأ عندما أرسلنا تعليمة متابعة في مهمة داخل تطبيق Windows الإصدار 26.915.31029. فيما يلي سجلات التطبيق بتاريخ 21 سبتمبر 2026 بعد تحويلها إلى التوقيت العالمي المنسّق (UTC)، مع حذف معرّفات المحادثات وتفاصيل العمل.
من إعادة المحاولة على الشاشة إلى إعادة التحميل الفعلية
فشل الإرسال (كانت الاستجابة الداخلية thread not found)
كانت الشاشة تعتبر المحادثة مستأنفة بالفعل
خطأ الإرسال نفسه بعد إعادة الفتح
تبديل الشاشة وحده لم يُحدث فرقًا
تأكيد حالة عدم التحميل → نجحت إعادة تحميل المحادثة
غير محمّلة → تقرّر أن الاستئناف لازم → نجح الاستئناف
قُبلت التعليمة التالية ونجحت معالجة الإرسال
أظهر فحص السجل لاحقًا أن الدورتين كانتا completed دون أخطاء
بقيت المحادثة المحفوظة ومجلد العمل، ونجحت أيضًا عملية قراءة السجل. ولم تكن المهمة الأصلية مؤرشفة.
ما الذي أكدته هذه الحالة
- السجل ما زال موجودًا
- نجح الإرسال بعد إعادة التحميل
- لم يُغيَّر السجل ولا الإعدادات أثناء الفحص
ما الذي لا تُظهره هذه الحالة
- المُحفِّز الدقيق الذي أدى إلى إلغاء تحميل المحادثة داخليًا
- السبب المشترك بين جميع المستخدمين
على الأرجح أن السبب هو عدم التطابق: الشاشة كانت تعامل المحادثة على أنها مستأنفة، بينما لم تكن محمّلة داخليًا. وبعد عودة الإرسال، تحقّق أيضًا من أن عمل ذلك الدور صحيح.
3. ترتيب المحاولات عند فشل الإرسال وحده
أولًا، احفظ نص رسالتك محليًا حتى لا تفقده. قبل الضغط على زر الإرسال مرة أخرى، تحقّق مما إذا كانت التعليمة نفسها قد أُضيفت إلى المحادثة، أو بدأت المعالجة بالفعل. وخاصة في التعليمات التي تتضمن النشر أو الحذف أو الشراء، من المهم ألا تُكدِّس طلبات تأخرت استجابتها.
تحقّق من المحادثة وآخر عمل قمت به
تحقّق مما إذا كان بإمكانك قراءة الرسائل السابقة، وهل تبدو آخر تعليمة مكتملة أو قيد التنفيذ أو بها خطأ. إذا لم تجد المهمة في القائمة، فافتح أيضًا «Archived chats» في الإعدادات (كما هو وارد في دليل استكشاف الأخطاء الرسمي). وإذا كانت لديك ملفات معدَّلة، فاحفظها ودوّن مكان العمل. وتعامل مع مشكلة عرض المحادثة بشكل منفصل عن فقدان ملفات العمل.
انتظر التحميل، ثم أعد فتح المهمة نفسها
إذا كنت قد فتحت المهمة للتو، فانتظر حتى يستقر عرض السجل. انتقل إلى مهمة أخرى لفترة ثم عُد، وجرّب فحصًا صغيرًا. في مثالنا لم يُصلح هذا الإجراء المشكلة وحده، لذلك بدلًا من تكرار إعادة الإرسال مرارًا، انتقل إلى الخطوة التالية.
تحقّق من الأعمال الأخرى، ثم أعد تشغيل التطبيق بالكامل
إذا كانت مهمة أخرى تعمل، فانتظر حتى تكتمل أو احفظ ما تحتاجه ثم أوقفها. بعد ذلك أغلق التطبيق، وأعد تشغيله، وافتح المهمة نفسها. تبديل عرض المهام وإعادة تشغيل التطبيق بالكامل عمليتان مختلفتان.
تأكّد من اكتمال رد قصير
لا تُعد إرسال العمل الكبير الأصلي فورًا، بل أرسل رسالة تحقق لا تتضمن تعديل ملفات ولا استخدام أدوات. وعند اكتمال الرد، تحقّق من محتوى العمل السابق ثم عُد إلى المتابعة المعتادة.
يمكنك تضييق نطاق رسالة التحقق على النحو التالي مثلًا. ولأنها تُرسل كتعليمة عادية إلى النموذج، فقد تُحتسب ضمن الاستخدام المعتاد.
هذا فحص للاتصال. لا تستأنف العمل السابق.
من دون قراءة الملفات أو كتابتها أو إجراء أي استدعاء للأدوات،
أجب بالعبارة التالية فقط: «تم استلام الرد.»يوجد في البلاغ عن مستودع OpenAI على GitHub رقم #30710 مثال لفشل إرسال مباشرةً بعد فتح محادثة على Windows، وقد حُلّ بإعادة التشغيل الكاملة للتطبيق. أما خطوة «انتظر اكتمال المهمة الجارية قبل إعادة التشغيل» الواردة في دليل استكشاف الأخطاء الرسمي، فهي إرشاد لحالة تجمّد الطرفية المدمجة، وليست موجهة لخطأ الإرسال هذا.
إذا قررت تجربة التحديث، فسجّل أولًا إصدار التطبيق الحالي والأعراض. وبحسب دليل استكشاف الأخطاء الرسمي، قد يختلف إصدار Codex المضمَّن في تطبيق سطح المكتب عن إصدار CLI المثبَّت بشكل منفصل. تحديث CLI لا يعني أن الخلل في التطبيق قد أُصلح.
4. الرسالة نفسها لا تعني سببًا واحدًا ولا حلًا واحدًا
لا تحكم بناءً على عبارة «Error submitting message» وحدها، بل انظر إلى الصياغة التي تليها وإلى العملية التي فشلت. يفصل الجدول التالي الأمثلة المأخوذة من البلاغات العامة ومن بيئتنا حسب الأعراض.
| العرض الظاهر | ما الذي يجب فحصه | ما لا يُفترض |
|---|---|---|
| يمكن قراءة السجل لكن الإرسال يفشل | هل يعمل الإرسال بعد إعادة التحميل؟ | قابلية قراءة السجل لا تعني قابلية الإرسال |
| فشل الأرشفة أيضًا / os error 2 | حالة ملفات الحفظ وما تشير إليه (غالبًا ما يبقى السجل قابلًا للقراءة) | حتى إذا عاد الإرسال بعد إعادة التشغيل، فقد تستمر الأرشفة في الفشل |
| Timeout / App server request expired while queued | هل انتُظر نحو 30 ثانية، أم توقفت الاستجابة، أم كان الطلب في قائمة الانتظار؟ | لا تخلط بينه وبين thread not found الذي يُعاد فورًا |
| يفشل الإيقاف كما يفشل الاستمرار | هل المهمة قيد التشغيل فعلًا، أم أن العرض قديم؟ | لا تعتمد على مؤشر التشغيل المعروض على الشاشة وحده |
في الحالات التي يبقى فيها السجل، تفيد الملاحظة الإضافية لمستخدم macOS في #30710. فقد كانت الشاشة تعامل المحادثة على أنها مستأنفة، لكن الإرسال استمر في الفشل، ثم نجحت لاحقًا إعادة التحميل في شاشة جديدة. وهذا بلاغ عن عدم تطابق في الحالة لا يمكن تفسيره بأنه «تزامن يحدث لحظة الفتح فقط»، ومساره يشبه كثيرًا الحالة الواردة هنا.
وفي المقابل، يصف بلاغ Windows رقم #39179 حالة يمكن فيها قراءة السجل بينما يفشل الإرسال والأرشفة، وقد استمرت في بيئة صاحب البلاغ بعد إعادة التشغيل. وتذكر متابعة لاحقة أنه بعد إعادة التشغيل الكاملة للتطبيق أمكن المتابعة، لكن فشل الأرشفة لم يُحَلّ بشكل مؤكد. ويتضمن #39575 تشخيصات تتعلق بالطوابع الزمنية في أسماء ملفات الحفظ وبعملية الإشارة إليها. وكلها تحقيقات أجراها المستخدمون، فلا تستنتج أن بياناتك تالفة لمجرد وجود بادئة في المسار أو فرق في التوقيت.
أما النوع الذي يتعرض للانتظار فيظهر في بلاغ مهلة الإرسال رقم #27395، ويتضمن سجلات قُطع فيها turn/start عند 30 ثانية (timeoutMs=30000) وفشل بوصفه Timeout. وفي متابعة للبلاغ #23644، انتظر طلبٌ يتوقف عليه الإرسال نحو 30 ثانية في قائمة الانتظار (queueWaitMs=30001)، ثم فشل بالرسالة App server request expired while queued. ويمكن الاطلاع على النوع الذي يفشل فيه الإيقاف أيضًا في بلاغ #42604 عن عدم تطابق السجل وحالة التنفيذ.
5. عند استمرار المشكلة: الفحوص والتسليم
إذا استمرت المشكلة بعد إعادة التشغيل، فتحقّق مما إذا كان يمكن قراءة السجل المحفوظ. وإذا كانت لديك ميزة تتيح لمهمة Codex سليمة أخرى قراءة المهمة المستهدفة، فابدأ بفحص للقراءة فقط. ومن المهم أيضًا ألا تخلط بين معرّف المهمة المستهدفة ومهمة لها اسم مشابه.
افحص المهمة المستهدفة في وضع القراءة فقط.
معرّف الهدف: معرّف المحادثة الذي يظهر في الخطأ
أبلغ عما إذا كان السجل قابلًا للقراءة، وعن حالة الدورة الأخيرة، وعن أي أخطاء.
لا ترسل رسائل إلى مهام أخرى، ولا تستأنف العمل السابق، ولا تُنشئ تفرّعًا (fork)،
ولا تؤرشف، ولا تغيّر الإعدادات، ولا تعدّل قاعدة البيانات، ولا تنقل ملفات السجل أو تحذفها.
إذا لم تكن وظيفة إدارة المهام متاحة، فأبلغ بذلك.هذا نص نموذجي للبيئات التي تتوفر فيها وظائف إدارة المهام. وإذا لم تجد هذه الوظيفة، فلا تخمّن أوامر داخلية بأسماء مشابهة ولا تنفّذها، بل انتقل إلى التقرير الوارد في القسم 6.
اختر الخطوة التالية وفق نتيجة الفحص
- يمكن قراءة السجل والعمل السابق مكتمل
- ضع في الاعتبار إرسال رسالة تحقق إضافية، أو إنشاء تفرّع ينقل السجل. واحتفظ بالمهمة الأصلية.
- يمكن قراءة السجل لكن لا يُعرف إن كان العمل قيد التنفيذ
- تحقّق أولًا من حالة التشغيل وتغييرات الملفات. ولا تُشغّل العمل نفسه مرتين في مهمة أخرى.
- يظهر خطأ في التخزين (مثل os error 2)
- احفظ نسخة احتياطية وأبلغ مع إرفاق السجلات. ولا تحذف الملفات الأصلية بهدف إصلاح التحميل.
تصف متابعة على #39179 حالة أُرسلت فيها رسالة تحقق قصيرة من مهمة سليمة أخرى، وبعد اكتمال الرد استُعيدت المحادثة العادية أيضًا. لكن متابعة أخرى تذكر أن إرسالًا مماثلًا فشل، وأن تعليمة جديدة قُبلت بعد إنشاء تفرّع من سجل مكتمل. وأمام هذا المثال المعاكس، أوضح صاحب البلاغ الأصلي أنه ليس حلًا عامًا.
التفرّع هو عملية تنقل السجل المكتمل إلى مهمة منفصلة، ولا يُصلح المهمة الأصلية. لا تفترض أن العمل غير المكتمل سيستمر تلقائيًا، بل تحقّق بعد التسليم من مجلد العمل والملفات المعدَّلة وآخر خطوة اكتملت.
وبيانات السجل وملفات العمل أيضًا أمران منفصلان. فقد تبقى تعديلات المشروع حتى إذا تعذّر فتح المحادثة. وعلى العكس، حتى إذا أمكن قراءة المحادثة فليس بالضرورة أن الملفات محدَّثة. وإذا كان مشروعك يستخدم Git، فراجع قائمة التغييرات وحدّد ما نُفّذ قبل المتابعة.
6. المعلومات الواجب تضمينها عند طلب فحص المشكلة
عند الإبلاغ، لا تكتفِ بقول «لا يمكن الإرسال»، بل فصّل ما نجح وما فشل. فوجود إصدار التطبيق ونظام التشغيل ووقت الحدوث والمنطقة الزمنية ومعرّف المحادثة المستهدفة والعملية التي سبقت الخطأ يجعل تتبع المشكلة أسهل، دون خلط بأعطال من مسار آخر. ولا حاجة إلى نشر نص المحادثة كاملًا منذ البداية.
نموذج ملاحظة التقرير
- البيئة
- إصدار التطبيق / نظام التشغيل / مكان التشغيل، مثل المحلي أو البعيد
- الحدوث
- الوقت والمنطقة الزمنية / نص الخطأ الكامل / العملية التي سبقت الخطأ
- ما يعمل وما لا يعمل
- نتائج عرض السجل / الإرسال / الإيقاف / الأرشفة
- العمليات التي جُرّبت
- ما الذي تغيّر قبل إعادة الفتح أو إعادة التشغيل وبعدهما
إذا كان بإمكانك فحص السجلات، فمن المفيد النظر إلى الأسطر التي تسبق الطلب الفاشل وتليه. تشير method=turn/start إلى بداية التعليمة، وthread/resume إلى استئناف المحادثة، وerrorCode دليل على الاستجابة الداخلية. واحتفظ أيضًا بالأسطر الناجحة، وميّز بين أن يظهر الفشل نفسه في عدة أسطر في السجل، وأنه فشل فعليًا عدة مرات.
أما مواقع سجلات التطبيق، فيذكر دليل استكشاف الأخطاء الرسمي المسار ~/Library/Logs/com.openai.codex/YYYY/MM/DD على macOS. وعلى Windows، وجدناها في بيئتنا في الموقعين التاليين.
- الجهاز الذي ظهر عليه الخطأ:
%LOCALAPPDATA%\Codex\Logs - جهاز آخر بنسخة Microsoft Store (سجلات مارس 2026):
%LOCALAPPDATA%\Packages\OpenAI.Codex_<ID>\LocalCache\Local\Codex\Logs(لم يكن في هذا الجهاز مجلد%LOCALAPPDATA%\Codexنفسه)
وبحسب شرح Microsoft، فإن الملفات التي يُنشئها تطبيق مُعبّأ جديدًا داخل AppData تُكتب في موقع خاص بالتطبيق، وقد تبدو للتطبيق كأنها في الموقع المعتاد. فإذا لم تجدها في أحدهما، فابحث في الآخر أيضًا. ويُذكر رسميًا أن مكان حفظ الجلسات هو $CODEX_HOME/sessions (والقيمة الافتراضية ~/.codex/sessions). وإذا اختلفت الإعدادات أو مكان التشغيل، فقد لا يكون الهدف موجودًا في المجلد الذي تنظر إليه، لذلك لا تحكم بأنه حُذف لمجرد أن «البحث لا يُظهره».
للاطلاع على ما وثّقناه بشأن أماكن البيانات بعد نقل Codex (CODEX_HOME) أو التطبيق نفسه إلى محرك أقراص آخر، راجع مقال نقل ChatGPT وCodex إلى محرك أقراص آخر.
يتضمن دليل استكشاف الأخطاء الرسمي إرشادًا لإرسال الملاحظات بكتابة / في حقل الإدخال. وقد تحتوي السجلات ولقطات الشاشة على نص المحادثة وعناوين البريد الإلكتروني وأسماء مشاريع أخرى ومسارات محلية. وفي بلاغ عام (Issue) انشر الأجزاء الضرورية فقط بعد إخفاء هويتها، وعند تسليم معرّفات كاملة وغيرها تحقّق من الجهة المرسل إليها ومن نطاق الاطلاع عليها.
7. تأكّد من الاستعادة برد قصير
الاستجابة الأولى لهذا الخطأ ليست حذف السجل، بل التحقق بشكل منفصل من إمكانية القراءة، وإمكانية الاستئناف، واكتمال التعليمة الجديدة. وفي هذه الحالة عاد الإرسال بعد إعادة تحميل المحادثة. أما إذا ظهر خطأ في التخزين فهو مسار مختلف، فانتقل إلى فحوص القسم 5.
عندما يكتمل الرد القصير، تحقّق إلى أي مدى نُفّذت التعليمة الأصلية، ثم استأنف من الخطوة اللازمة. وإن لم تُحل المشكلة، فأعطِ الأولوية للفحص للقراءة فقط وحفظ السجلات. ومن المهم ألا تعتبر الاستعادة مكتملة لمجرد اختفاء رسالة الخطأ، أو لمجرد إمكانية إنشاء تفرّع.
مقالات ذات صلة:
- الفرق بين أخطاء سعة Codex ونفاد حصة الاستخدام، وطرق معالجتها (عندما يظهر «Selected model is at capacity»)
- شروط اتصال Remote وخطوات الفحص بعد الانقطاع (مكان التشغيل وسكون الجهاز)
- أخطاء مشابهة في Claude Code: Prompt is too long (حجم الإدخال) وMCP error -32000: Connection closed (الاتصال بالأدوات الخارجية)
الأسئلة الشائعة
س. إذا ظهر thread not found، فهل اختفت المحادثة؟
ج. ليس بالضرورة. فقد يمكن قراءة السجل المحفوظ بينما لم تُحمَّل المحادثة اللازمة للتنفيذ بوصفها هدف الإرسال. ومن جهة أخرى، قد تكون هناك مشكلة في مرجع التخزين أو في الملفات نفسها، لذلك نتحقق مما إذا كان يمكن قراءتها فعليًا.
س. هل notLoaded خطأ؟
ج. هذه الحالة في حد ذاتها طبيعية. فهي تعني أن المحادثة المحفوظة غير محمّلة حاليًا للتنفيذ. وتصبح مشكلة فقط عندما لا تُستأنف عند متابعة العمل، ولا يكتمل حتى الرد القصير.
س. هل تُصلح إعادة التشغيل المشكلة دائمًا؟
ج. ليس دائمًا. توجد بلاغات قالت إن إعادة التشغيل الكاملة أصلحت المشكلة (#30710)، وبلاغات بقي فيها فشل الإرسال والأرشفة بعد إعادة التشغيل (#39179). وفي مثالنا عاد الإرسال بعد إعادة تحميل المحادثة.
س. هل يحل التحديث إلى أحدث إصدار المشكلة؟
ج. حتى 21 سبتمبر 2026، لم نجد إصدارًا مُصلحًا يذكر صراحةً أنه عالج هذا العرض بالكامل. وعند التحديث، سجّل إصدار التطبيق قبله وبعده والنتائج. وCLI المثبَّت بشكل منفصل وCodex المضمَّن في التطبيق ليسا بالضرورة بالإصدار نفسه.
