تحديث Entergram - أسبوع 25 يونيو 2026: الاستقرار وأدوات البروكسي وأكثر من 25 إصلاحًا

كان هذا أسبوعًا هندسيًا عميقًا في Entergram. أطلقنا ميزتين جديدتين في البنية التحتية، وحسّنّا الاستقرار بدرجة كبيرة لمساحات العمل ذات الحجم العالي، وأغلقنا أكثر من 25 خللًا تمتد عبر المراسلة وإدارة الاتصالات والتهيئة والفوترة وجدول إدارة العملاء. إليك كل ما وصل إلى الإنتاج.

صار بإمكان المشرفين نسب حركة البروكسي إلى مسارات وحسابات متصلة بعينها، فتتضح أي الاتصالات تستهلك أكبر قدر من عرض النطاق. وإلى جانب ذلك، يمكنك الآن تخصيص بروكسي ثابت مخصص لمسارات منفردة، وهو مفيد حين تحتاج إلى عنوان IP ثابت ومتوقع لحسابات تيليجرام محددة بدل ترك المجمع يدوّر العناوين.

DEV-149 على Linear

صار عامل خلفي يفحص كل بروكسي دوريًا ويحدّث حالته الصحية. وهذا يعني أن لوحة الإدارة تعكس حالة الاتصال الحقيقية، فتلتقط البروكسي المتدهور قبل أن يؤثر في مستخدميك بصمت، بدل اكتشاف المشكلة عبر تذاكر الدعم.

DEV-151 على Linear

لماذا يهم هذا عمليًا؟ لأن كل حساب تيليجرام في Entergram يُوجَّه عبر بروكسي خاص به. جودة تلك الطبقة هي ما يحدد شعور الفريق بسرعة صندوق الوارد، وهي أيضًا ما يحمي الحسابات من أنماط اتصال غير طبيعية. حين تصبح صحة البروكسي مرئية ومسندة إلى مسار محدد، يتحول سؤال "لماذا هذا الحساب بطيء اليوم؟" من تخمين إلى فحص من خطوة واحدة.

كانت مساحات العمل الكبيرة، أي تلك التي تضم مئات المحادثات عبر حسابات متصلة كثيرة، تعاني من حجب ملحوظ للخيط الرئيسي وبطء في المتصفح. أعدنا هذا الأسبوع هيكلة محرك الاتصال ws-v2 لتنظيم دفعات account.bind وضبط وتيرة استدعاءات folder.chats.fetch. والنتيجة: جلسة اختبار جودة كانت تنتج سابقًا 692 مهمة طويلة وقرابة 166 ثانية من حجب الخيط الرئيسي صارت تُحمَّل بسلاسة.

DEV-191 على Linear

كانت الحسابات في مساحات العمل المزدحمة تعرض شارة "إعادة الاتصال مطلوبة / غير متصل" حتى عندما تكون جلسة MTProto في الخلفية حية وتخدم الحركة فعليًا. وكان المشغّلون الذين ينقرون "إعادة الاتصال" يطلقون عمليات تسجيل دخول غير ضرورية، ويصطدمون أحيانًا بحدود FLOOD_WAIT من تيليجرام على رقم الهاتف. الآن لا تظهر الشارة إلا عند وجود مشكلة اتصال حقيقية.

DEV-177 على Linear

الرسائل الصوتية تعمل من جديد. كانت الرسائل الصوتية الواردة تفشل بصمت، فلا يفعل زر التشغيل شيئًا. أُصلح ذلك في جميع أنواع المحادثات. (DEV-133)

حل أخطاء "Socket closed". كانت عدة مساحات عمل تعاني من انقطاعات حادة مصحوبة بخطأ سياق chat.subscribe. صار منطق إعادة اتصال السوكت مستقرًا. (DEV-120)

سجل المجموعات الكبرى والقنوات يُحمَّل بشكل صحيح. كان التنقل داخل المجموعات الكبرى يطلق أخطاء "Invalid realtime command payload" على مسار history.around حين ترسل الواجهة تلميحات نظير (entity_class_name) لا تعرفها البوابة. أُصلح ذلك على مستوى البوابة. (DEV-168, PRODUCT-121)

الصفحة لم تعد تتجمد أثناء المحادثة أو إعادة التوجيه. حُلّت فئة من مشكلات التجمد وإعادة التحميل التي كانت تصيب المشغّلين في منتصف المحادثة. (DEV-143)

حالة الاتصال صارت متسقة. كان مؤشر التواجد في جدول المحادثات ومؤشر رأس نافذة المحادثة يقرآن من مصدرين مختلفين. صارا يتشاركان حالة تواجد واحدة. (DEV-186)

أسماء المرسلين صحيحة في المجموعات. كانت فقاعات الرسائل في سلاسل المجموعات تعرض أحيانًا اسم مستخدم تيليجرام الخطأ فوق محتوى الرسالة. أُصلح ذلك في مسارَي chat_list.window.snapshot وlive_chat_list.delta. (DEV-192)

عدّادات غير المقروء صارت دقيقة. كانت عدة سيناريوهات تجعل شارة غير المقروء تبالغ في العد، مثل إرسال رسالتين وظهور خمس رسائل غير مقروءة. صار العدّاد يوفّق نفسه بشكل صحيح عبر عمليات إعادة الاتصال. (DEV-135)

إصلاح تكرار فقاعات الرسائل. حين يشترك حسابان متصلان أو أكثر في المحادثة نفسها، كانت الرسالة الواحدة تظهر مرتين في السلسلة المفتوحة. كان السبب خللًا في إزالة التكرار عند العرض في الواجهة، لا مشكلة في دمج الحسابات. أُصلح. (DEV-183)

حل مشكلة المرسل البديل وفاعلي التفاعلات. كان سجل المحادثة يعرض أحيانًا other كاسم مرسل للرسائل الواردة، وكانت نوافذ التفاعلات عالقة على "Loading reactions". أُصلح الأمران. (DEV-156)

المحادثات تبقى في عرض المجلد بعد ردّك. كانت المجلدات التي تحمل خاصية "استبعاد المحادثات المقروءة" تُخرج المحادثة فور إرسال المشغّل ردًا، فتختفي في منتصف الجلسة. صارت المجلدات تُبقي المحادثات التي رددت عليها حتى تغادر الصفحة. (DEV-178)

إرسال MCP إلى جهات اتصال جديدة. كان تكامل MCP يعطي خطأ عند محاولة إرسال رسالة إلى جهة اتصال على تيليجرام لم تسبق محادثتها. صارت عمليات الإرسال الأولى تعمل بشكل صحيح. (DEV-141)

الجلسات المتوقفة تتعافى تلقائيًا. تسبب خلل في منطق سعة المسارات داخل وكيل الجلسات (observeRoutes) بتوقف بعض الجلسات عن إعادة التشغيل بعد انقطاعها. وكانت الحسابات المتأثرة تُظهر nats: no responders مع كل طلب سجل أو مجلد، ولم تكن إعادة تشغيل الوكيل تنفع. حُلّت مشكلة التجويع، وصارت الجلسات المتوقفة تحيي نفسها. (DEV-139)

نافذة اتصال ws-v2 لم تعد تغرق الواجهة بأخطاء 400. تسببت مشكلة توقيت في استمرار حلقة الاستطلاع بالسؤال عن معرّف جلسة مصادقة غير موجود، فأنتجت مئات من تنبيهات API request failed: 400 في جلسة واحدة. أُصلح ذلك في دورة حياة الاستطلاع. (DEV-181)

حالة اتصال البروكسي تظهر بشكل صحيح في الإعدادات. كان مؤشر البروكسي عالقًا على "جارٍ التحميل" كلما زرت صفحة الإعدادات، حتى مع الاتصالات السليمة. صار يعكس الحالة الحية الفعلية. (DEV-154)

المستخدمون ينضمون إلى مساحات العمل بموثوقية. كان عطل React من نوع تجاوز الحد الأقصى لعمق التحديث (#185) يقع كلما وصل مستخدم جديد إلى جدول محادثات إدارة العملاء بعد الانضمام. السبب الجذري كان مرجع مصفوفة يُعاد إنشاؤه في كل عملية عرض داخل تعريف CHAT_PAGE_SIZE_OPTIONS، وقد نُقل الآن خارج دورة العرض. (DEV-165, DEV-167)

إصلاح قبول الدعوات أثناء التهيئة. كان المستخدمون الذين يلصقون رابط دعوة لمساحة عمل أثناء التهيئة يكملون المسار دون الانضمام فعليًا إلى مساحة العمل المقصودة، فينتهي بهم الأمر في مساحة شخصية فارغة ثم يقع عطل عند الانتقال إلى الإعدادات أو جدول المحادثات. صار منطق قبول الدعوة وإعادة التوجيه صحيحًا. (DEV-170)

المستخدمون المحذوفون لم يعودوا يظهرون مجددًا. كان أعضاء مساحة العمل الذين أُزيلوا أو غادروا يُعادون مع كل تحديث للصفحة عبر جلسة رابط دعوة قديمة. صارت نقطة النهاية /api/onboarding تتحقق من حالة العضوية قبل إعادة الانضمام. (DEV-175)

يمكن إلغاء طلبات تغيير البريد الإلكتروني. لم يكن زر الإلغاء لطلب تغيير بريد معلق مربوطًا بأي إجراء، فلم يكن النقر عليه يفعل شيئًا. صار يلغي الطلب المعلق فعلًا. (DEV-137)

تحديد المحادثات مرئي في السمة الفاتحة. كان تحديد صفوف المحادثات في السمة البيضاء ينتج إبرازًا غير مرئي تقريبًا بسبب غياب رمز تباين. أُصلح. (DEV-157)

أصحاب الحسابات التجريبية يشترون المقاعد دون الاصطدام بطريق مسدود. استدعاء purchaseSeat() قبل امتلاك المالك اشتراكًا مدفوعًا نشطًا يعيد 400 OWNER_SUBSCRIPTION_REQUIRED. صار أصحاب التجربة يرون رسالة واضحة تدعوهم إلى الاشتراك أولًا، مع مسار مباشر إلى صفحة الاشتراك. (DEV-174)

عمليات شراء الاشتراك تعمل بموثوقية. حُلّت فئة من تعارضات المصادقة 401/403 عند الدفع، وكان سببها إبطال الجلسة أثناء إعادة التوجيه إلى Stripe. (DEV-172)

الوسائط والفيديو تعمل دون أخطاء تجاوز الحد. كانت نقطة النهاية /api/realtime/media خاضعة لمحدد عام بمعدل 20 طلبًا في الدقيقة. وبث الفيديو في المتصفح يصدر عدة طلبات نطاق بايت للملف نفسه، فيتجاوز المحدد في أقل من ثانية. صارت طلبات الوسائط تتخطى المحدد العام. (DEV-152)

البحث صار كاملًا ومتسقًا. كانت بعض عمليات البحث تعيد نتائج جزئية أو تفشل برسالة "Telegram Search is unavailable" في المحاولة الأولى، ثم تنجح في المحاولات التالية للمصطلح نفسه. أُصلح ذلك، وصارت النتائج تعود بشكل صحيح من الطلب الأول. (DEV-136)

"الوقت منذ أول رسالة واردة" يُحسب من تيليجرام لا من فتح التطبيق. كان العمود الخاص يبدأ عدّه من لحظة فتحك Entergram بدل لحظة استلام تيليجرام للرسالة أول مرة. صار مصدر الطابع الزمني صحيحًا. (DEV-162)

قد تبدو قائمة من الإصلاحات التقنية بعيدة عن العمل اليومي، لكن أثرها المجمّع ملموس في ثلاثة مواضع تحديدًا.

صندوق الوارد متعدد الحسابات على نطاق واسع. الفرق التي تشغّل عشرات الحسابات المتصلة داخل مساحة عمل واحدة هي الأكثر تضررًا من حجب الخيط الرئيسي وشارات إعادة الاتصال الكاذبة. إذا كان فريقك قد اعتاد تحديث الصفحة عند كل بطء، جرّب سير عملك المعتاد من جديد هذا الأسبوع قبل تغيير أي إعداد، فالسلوك الأساسي تغيّر.

دقة الأرقام قبل قراءتها. عدّادات غير المقروء وعمود "الوقت منذ أول رسالة واردة" يغذيان القرارات: من يتابع ماذا، وأي محادثة تأخرت. الأرقام الخاطئة أسوأ من غياب الأرقام، ولهذا عولج هذان الخللان ضمن هذه الدفعة.

حسابات أكثر أمانًا. تقليل عمليات إعادة تسجيل الدخول غير الضرورية يقلل احتمال اصطدام رقم الهاتف بقيود FLOOD_WAIT من تيليجرام، ومراقبة صحة البروكسي تمنحك إنذارًا مبكرًا بدل انقطاع مفاجئ. بالنسبة إلى الفرق التي تعتمد على حسابات شخصية حقيقية في المبيعات والدعم، هذه ليست تفاصيل ثانوية بل استمرارية عمل.

1. افتح إعدادات مساحة العمل وتحقق من حالة البروكسي لكل حساب متصل، فالمؤشر صار يعكس الحالة الحقيقية.
2. راجع مجلداتك التي تستخدم خيار استبعاد المحادثات المقروءة، وأعد تقييم ما إذا كانت لا تزال مناسبة بعد تغيّر سلوك بقاء المحادثة بعد الرد.
3. إن كنت قد أوقفت استخدام المحادثات الصوتية أو تشغيل الفيديو بسبب الأعطال السابقة، فأعد إدخالهما إلى سير عملك.
4. إذا كان لديك أعضاء أُزيلوا سابقًا وظلوا يظهرون بعد التحديث، فتحقق من قائمة الأعضاء مرة واحدة للتأكد من أن الحالة صحيحة الآن.

سجل التغييرات الكامل للإصدار v0.16.0 وجميع الإصدارات السابقة متاح على صفحة ما الجديد في Entergram.