संचार मार्ग पर क्वेरी स्ट्रिंग को दोहराने से रोकें

Fixkamo-internal
शिप
5 अगस्त 2026 को 7:01 pm बजे UTC
लेखक
Kamo
Commit
8b95800

सभी / कॉल / टेक्स्ट / ईमेल विफल हो गए "हम इस लीड को लोड नहीं कर सकते थे" संचार बैकएंड ठीक था - प्रत्यक्ष कॉल वास्तविक के साथ 200 वापस लौट आए प्रविष्टियाँ BFF मार्ग अनुरोध को भ्रष्ट कर रहा था। आगे ToApi पहले से ही कॉलर के क्वेरी स्ट्रिंग को माध्यम से ले जाती है (`new URL(request.url).search`). इस मार्ग ने अपना खुद का प्रत्यय भी बनाया, इसलिए अग्रेषित URL में दो `?` था। यह एक वाक्यविन्यास त्रुटि नहीं है: उसके बाद सब कुछ FIRST `?` क्वेरी स्ट्रिंग है, इसलिए बैकएंड प्राप्त हुआ `size=25?channel=ALL` और स्प्रिंग ने 400 को एक int में बांध दिया ("Input स्ट्रिंग के लिए: 25?channel=ALL, 25")। अगले दरवाजे की गिनती थी अप्रभावित क्योंकि यह कोई परिमाण नहीं है - जो वास्तव में क्यों टैब देखा है स्पष्ट रूप से गलत होने के बजाय आधे टूट गए। दो चीजें यह पता लगाने के लिए लंबे समय तक की जानी चाहिए, दोनों निश्चित: मार्ग हर अपस्ट्रीम विफलता को एक अपारदर्शी स्ट्रिंग में गिर गया, और ग्राहक ने स्थिति को दूर कर दिया। अब दोनों लॉग वास्तव में वापस आए। आगे यह भी दस्तावेज है कि यह क्वेरी स्ट्रिंग का मालिक है, क्योंकि जाल में अदृश्य है कॉल साइट.

सभी बदलाव

जैसा कि आप शिपिंग देखते हैं?

इन अद्यतनों में से प्रत्येक स्वचालित रूप से अपने कार्यक्षेत्र में उतरता है। प्रारंभ करें और सप्ताह के बाद इसे सप्ताह के अंत में देखें।.

Foreverमूल्य निर्धारण देखें