از رفع یک باگ تا Contributor شدن در Sentry

چند ماهی از ورودم به کارنامه میگذشت و تقریبا هرروز که Sentry رو باز میکردم یک Exception اون بالا میدیدم، که هر دقیقه با اجرای تسک‌های Celery ما تکرار میشد! این Exception از داخل کدهای Sentry(SDK) بود و اعصاب بچه‌های تیم رو بهم ریخته بود، چون هر چقدر کانفیگ پروژرو تغییر میدادن تاثیری نداشت.

داخل این نوشته میخوام توضیح بدم که چطور یک تغییر کوچیک داخل کدهای Sentry(SDK) باعث شد که من Contributor بشم و این Exception هم دیگه داخل داشبورد Sentry ندیدیم، پس همراه من باشید.

مشکل: KeyError عجیب و غریب

مشکل ما یک KeyError بود که بعد از اتمام اجرای یک تسک Celery رخ میداد و میدونیم این زمانی رخ میده که بخوایم به یک کلید درون دیکشنری پایتونی دسترسی پیدا کنیم، ولی اون کلید وجود نداره.

اینجا بود که دیدم ابزاری که ما برای رفع خطاها استفاده میکردیم، خودش عامل این Exception بود.

پیدا کردن ریشه‌ی مشکل

از اونجایی که خیلی آدم پیگیری هستم، دیدم که اینطوری نمیشه و شروع کردم به گشت و گذار داخل کدهای کتابخانه Sentry Python تا بتونم این مشکل رو حل کنم و حتی شاید بتونم Contributorهم بشم.
با یکم وقت گذاشتن و خوندن کدها، متوجه شدم که Sentry(SDK) قبل از اجرا شدن تسک های Celery، یک سری Metadata ست میکنه، مثلا زمان شروع اجرای تسک و اطلاعات دیگه. و بعد از اون تسک اجرا میشد و تمام.
اما چه تمام شدنی، تازه اینجا بود که Sentry میخواست مانیتور کنه که تسک چقدر طول کشید که کامل بشه و دقیقا اینجا بود که اون Metadata رو پیدا نمیکرد و باعث میشد دیکشنری پایتونی ما کلیدی که انتظار داشت رو نداشته باشه و به KeyError میخورد. من خیلی سعی کردم که روی لوکالم بتونم دیباگ کنم که چرا این اتفاق میفته، ولی اینجا بود که این جمله همیشگی اتفاق افتاد:

رو لوکال من داره کار میکنه :)

اما واقعا اینطوری بود که من روی پروداکشن فقط این Exception رو میدیدم و هرکاری میکردم روی سیستم خودم هیچ خبری نبود. این مشکل میتونست به خاطر OS یا پکیج های دیگه ای که روی اون نصب بود باشه. اما من نه وقت و نه دسترسی لازم برای بررسی کردن این موارد رو داشتم.

اما میتونستم یک کار ساده تر و موقتی برای رفع این مشکل انجام بدم، اون هم این بود که هرکجا که Sentry(SDK) اومده از این تیکه کد استفاده کردرو تغییر بدم:

float(headers[&quotsentry-monitor-start-timestamp-s&quot])

هممون میدونیم که با متود get میشه به کلید دیکشنری دسترسی پیدا کرد و اگر کلید وجود نداشت KeyError رخ نده. اما صبر کنید، اگر این کلید وجود نداشت، من باید چه مقدار پیش فرضی رو در نظر میگرفتم؟

اینجا بود که گفتم اگر بخوام تغییری بدم و Contribute بکنم، باید تست های Sentry(SDK) کامل پَس بشن و نمیتونم همینجوری مقدار پیش فرض رو صفر یا مقدار دیگه ای در نظر بگیرم و ممکنه تست ها پَس نشن. به خاطر همین گفتم یک نگاهی هم به تست های این کتابخانه بندازم. خوشبختانه دیدم که اگر مقدار sentry-monitor-start-timestamp-s رو None در نظر بگیرم، تست ها به درستی پَس میشن!
منطقی هم بود، چون مانیتور کردن اینکه زمان اجرای این تسک چقدر بوده مهم نبود(حداقل برای ما) و خود لاگ های Celery Beat هم این دیتا رو به ما میداد...

در نهایت با بررسی کدهای کتابخانه پایتونی Sentry و نگاه کردن به تست های پروژشون، دیدم که میتونم خیلی راحت اون تیکه کد رو به این تغییر بدم و مشکلمون حل بشه:

headers.get(&quotsentry-monitor-start-timestamp-s&quot)

با استفاده از متود get از رخ دادن KeyError جلوگیری کردم و مقدار پیش فرض هم None در نظر گرفتم و چند خط از کدهای کتابخونرو همینجوری تغییر دادم.

از باگ تا انتشار

وقتی دیدم تونستم این مشکل رو حل کنم، گفتم چرا به عنوان Issue داخل گیت هاب مطرحش نکنم؟ اصلا شاید ما جایی داریم اشتباه میکنیم و توسعه دهنده های خود Sentry بیان و مارو راهنمایی کنن. که این کار رو انجام دادم و با صحبت هایی که با این تیم داشتم و لاگ‌هایی که در اختیارشون قرار دادم، مشکلی از سمت کانفیگ‌های مارو متوجه نشدن و به نظر همه چیز داخل کدهای ماهم درست بود و مشکلی رو پیدا نکردیم. پس در نهایت قبول کردند که این تغییرات در Sentry Python مرج بشه، چرا که حداقل از نظر Best Practice بهتر هم هست.

Release: Sentry Python 2.11.0 released
Issue: #3277
Pull Request: #3278

نتیجه گیری

این تجربه به من نشون داد که مشکلات به ظاهر کوچیک، فرصتی برای یادگیری و رشد هستند. با بررسی کدهای Sentry(SDK) و مشارکت در پروژه اوپن سورس، نه تنها مشکل تیم رو حل کردم، بلکه به جامعه توسعه دهندگان هم کمک کردم تا از بروز همان خطا جلوگیری کنند.