به‌روزرسانی Entergram - هفته ۲۵ ژوئن ۲۰۲۶: پایداری، ابزارهای پروکسی و بیش از ۲۵ رفع اشکال

این هفته در Entergram هفته‌ای عمیقاً مهندسی بود. دو قابلیت زیرساختی تازه منتشر کردیم، پایداری فضاهای کاری پرحجم را به‌طور محسوسی بهتر کردیم و بیش از ۲۵ اشکال را در پیام‌رسانی، مدیریت اتصال، مسیر آغاز به کار، صورتحساب و جدول CRM بستیم. در ادامه همه آنچه فرود آمد را می‌خوانید.

مدیران حالا می‌توانند ترافیک پروکسی را به مسیرها و حساب‌های متصل مشخصی نسبت دهند و ببینند کدام اتصال بیشترین پهنای باند پروکسی را مصرف می‌کند. در کنار آن، می‌توانید پروکسی ثابت اختصاصی به هر مسیر بدهید؛ این وقتی مفید است که برای حساب‌های تلگرام خاصی به یک IP قابل پیش‌بینی و پایدار نیاز دارید و نمی‌خواهید استخر بچرخد.

DEV-149 در Linear

یک کارگر پس‌زمینه حالا به‌صورت دوره‌ای هر پروکسی را می‌آزماید و وضعیت سلامتش را به‌روز می‌کند. یعنی پنل مدیریت وضعیت واقعی اتصال را نشان می‌دهد و می‌توانید پروکسی‌های افت‌کرده را پیش از آنکه بی‌سروصدا کاربران را درگیر کنند بگیرید، به‌جای اینکه از راه تیکت پشتیبانی متوجه مشکل شوید.

DEV-151 در Linear

فضاهای کاری بزرگ، یعنی آنهایی که صدها چت روی حساب‌های متصل متعدد دارند، با مسدودشدن جدی رشته اصلی و کندی مرورگر روبه‌رو بودند. این هفته موتور اتصال ws-v2 را بازنویسی کردیم تا انفجار فراخوانی‌های account.bind را محدود کند و فراخوانی‌های folder.chats.fetch را آهنگ‌دار کند. نتیجه: نشست تضمین کیفیتی که قبلاً ۶۹۲ وظیفه طولانی و حدود ۱۶۶ ثانیه مسدودی رشته اصلی تولید می‌کرد، اکنون تمیز بارگذاری می‌شود.

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 نشان می‌داد و پنجره واکنش‌ها روی «در حال بارگذاری واکنش‌ها» گیر می‌کرد. هر دو رفع شد. (DEV-156)

چت‌ها بعد از پاسخ در نمای پوشه می‌مانند. پوشه‌هایی با گزینه «حذف چت‌های خوانده‌شده» به‌محض ارسال پاسخ توسط اپراتور چت را بیرون می‌انداختند و گفتگو وسط کار ناپدید می‌شد. پوشه‌ها حالا چت‌های پاسخ‌داده‌شده را تا وقتی از صفحه خارج شوید نگه می‌دارند. (DEV-178)

ارسال MCP به مخاطبان تازه. یکپارچه‌سازی MCP هنگام تلاش برای ارسال پیام به مخاطبی که هرگز با او چت نکرده بودید خطا می‌داد. ارسال‌های اولین‌بار حالا درست کار می‌کنند. (DEV-141)

نشست‌های مرده خودکار احیا می‌شوند. اشکالی در منطق ظرفیت مسیر عامل نشست (observeRoutes) باعث می‌شد بعضی نشست‌ها پس از مرگ دیگر راه‌اندازی نشوند. حساب‌های درگیر روی هر درخواست تاریخچه یا پوشه پیام nats: no responders می‌دادند و راه‌اندازی مجدد عامل هم کمکی نمی‌کرد. مشکل قحطی منابع رفع شد و نشست‌های مرده حالا خودشان زنده می‌شوند. (DEV-139)

دیالوگ اتصال ws-v2 دیگر سیل خطای ۴۰۰ راه نمی‌اندازد. یک مشکل زمان‌بندی باعث می‌شد حلقه نظرسنجی اتصال حساب مدام سراغ شناسه نشست احراز هویتی بگیرد که وجود نداشت و صدها پیام API request failed: 400 در یک نشست تولید کند. در چرخه عمر نظرسنجی رفع شد. (DEV-181)

وضعیت اتصال پروکسی در تنظیمات درست نمایش داده می‌شود. نشانگر پروکسی هر بار که صفحه تنظیمات را باز می‌کردید روی «در حال بارگذاری» گیر می‌کرد، حتی برای اتصال‌های سالم. حالا وضعیت زنده واقعی را نشان می‌دهد. (DEV-154)

کاربران مطمئن به فضای کاری می‌پیوندند. یک کرش React از نوع بیشینه عمق به‌روزرسانی (#185) هر بار که کاربر تازه پس از پیوستن روی جدول چت CRM می‌نشست رخ می‌داد. ریشه مشکل ارجاع آرایه‌ای بود که مدام داخل تعریف 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)

خرید اشتراک مطمئن کار می‌کند. دسته‌ای از تعارض‌های احراز هویت ۴۰۱ و ۴۰۳ هنگام پرداخت، که از باطل شدن نشست در جریان هدایت به Stripe می‌آمد، برطرف شد. (DEV-172)

رسانه و ویدئو بدون خطای محدودیت نرخ پخش می‌شوند. اندپوینت /api/realtime/media زیر یک محدودکننده عمومی ۲۰ درخواست در دقیقه بود. پخش ویدئو در مرورگر چند درخواست بازه بایتی برای یک فایل می‌فرستد و در کمتر از یک ثانیه محدودکننده را فعال می‌کرد. درخواست‌های رسانه حالا از محدودکننده عمومی عبور می‌کنند. (DEV-152)

جستجو کامل و یکدست است. بعضی جستجوها نتایج ناقص برمی‌گرداندند یا در اولین درخواست خطای «جستجوی تلگرام در دسترس نیست» می‌دادند، در حالی که جستجوهای بعدی همان عبارت کار می‌کرد. رفع شد و نتایج حالا در همان درخواست اول درست برمی‌گردند. (DEV-136)

«زمان سپری‌شده از اولین پیام ورودی» از تلگرام شمرده می‌شود، نه از باز شدن برنامه. این ستون ویژه ساعتش را از لحظه باز کردن Entergram شروع می‌کرد، نه از لحظه‌ای که پیام اولین بار در تلگرام دریافت شده بود. منبع زمان حالا درست است. (DEV-162)

یادداشت انتشاری با این حجم رفع اشکال، بیش از آنکه فهرست باشد یک پیام دارد: کار روی زیرساختی متمرکز بوده که فضاهای کاری بزرگ را سرپا نگه می‌دارد. اگر ده‌ها حساب تلگرام را در یک فضای کاری اداره می‌کنید، سه تغییر بیشترین اثر را در کار روزانه‌تان خواهند داشت.

اول، پایدارسازی ws-v2. اگر تیم شما پیش از این عادت کرده بود روزی چند بار صفحه را رفرش کند تا پوشه‌ها درست بارگذاری شوند، آن عادت را کنار بگذارید و یک نشست کاری کامل را بدون رفرش امتحان کنید. کندی رابط کاربری در فضاهای کاری بزرگ اغلب نتیجه سخت‌افزار ضعیف نبود؛ نتیجه انفجار فراخوانی‌ها در لحظه اتصال بود.

دوم، نشان نادرست «نیاز به اتصال مجدد». این مورد بیش از یک آزار بصری بود. هر کلیک غیرضروری روی اتصال مجدد یک ورود تازه به تلگرام راه می‌انداخت و ورودهای پشت سر هم روی یک شماره می‌توانست به FLOOD_WAIT ختم شود، یعنی همان وقفه اجباری که هیچ تیم فروشی وسط روز کاری نمی‌خواهد. اگر در تیم شما رویه نانوشته‌ای وجود دارد که «هر وقت نشان قرمز دیدی، اتصال مجدد بزن»، حالا وقت به‌روزرسانی آن رویه است: نشان را جدی بگیرید، چون دیگر بی‌دلیل روشن نمی‌شود.

سوم، ابزارهای پروکسی. برای تیم‌هایی که در ایران، خاورمیانه و دیگر بازارهایی کار می‌کنند که کیفیت مسیر شبکه ثابت نیست، پایداری پروکسی مستقیماً به نرخ تحویل پیام گره خورده است. پایشگر سلامت یعنی مدیر فضای کاری می‌تواند افت یک مسیر را پیش از آنکه به شکایت کارشناسان تبدیل شود ببیند، و پروکسی ثابت اختصاصی یعنی حساب‌های حساس‌تر می‌توانند روی یک IP قابل پیش‌بینی بمانند.

پیشنهاد می‌کنیم مدیر فضای کاری چند دقیقه وقت بگذارد و این چهار مورد را بررسی کند:

1. صفحه تنظیمات را باز کنید و وضعیت پروکسی هر حساب متصل را ببینید. نشانگر دیگر روی حالت بارگذاری گیر نمی‌کند، پس آنچه می‌بینید وضعیت واقعی است.
2. حساب‌هایی که نشان قطع‌شدگی می‌گیرند را فهرست کنید. بعد از این انتشار، این فهرست باید کوتاه باشد. هر موردی که باقی مانده احتمالاً یک مشکل واقعی اتصال است و ارزش بررسی دارد.
3. پوشه‌هایی که گزینه حذف چت‌های خوانده‌شده دارند را دوباره امتحان کنید. رفتار جدید یعنی کارشناس می‌تواند پاسخ بدهد و همچنان گفتگو را جلوی چشم داشته باشد؛ شاید بعضی پوشه‌هایی که تیم به‌خاطر رفتار قدیمی کنار گذاشته بود دوباره به کار بیایند.
4. ستون «زمان سپری‌شده از اولین پیام ورودی» را یک بار مرور کنید. حالا که منبع زمان درست شده، این ستون معیار قابل اتکایی برای سرعت پاسخ‌گویی اول است و می‌تواند مبنای مرتب‌سازی صف روزانه باشد.

اگر تیمی چندزبانه دارید، این ستون همراه با فیلترهای حساب راه ساده‌ای برای دیدن این است که کدام زبان یا کدام بازار بیشترین تأخیر پاسخ اول را دارد، بدون آنکه لازم باشد گزارش جداگانه‌ای بسازید.

ما هفتگی منتشر می‌کنیم و یادداشت‌های انتشار را عمداً با شماره مسئله در Linear می‌نویسیم. دلیلش ساده است: وقتی مشکلی گزارش می‌کنید، می‌خواهیم بتوانید مسیرش را تا رفع شدن دنبال کنید. اگر اشکالی که گزارش کرده‌اید در این فهرست نیست، به این معنا نیست که فراموش شده؛ به این معناست که هنوز در صف است.

فهرست کامل تغییرات نسخه v0.16.0 و همه انتشارهای پیشین در صفحه تازه‌های Entergram در دسترس است.