شكرًا لك على اختبار ذلك.
في هذه الحالة، لا أعتقد أن إضافة الذكاء الاصطناعي هي السبب المرجح. قد يكون مجرد مصادفة، أو ربما أدى دورة التعطيل وإعادة التمكين إلى تغيير حالة عابرة مؤقتًا.
أكثر ما يفيد بعد ذلك هو توثيق توقيت الطلبات ونمط ظهور التحذير.
على سبيل المثال:
curl -s -o /dev/null \
-w "total=%{time_total}s connect=%{time_connect}s starttransfer=%{time_starttransfer}s\n" \
-X POST "https://your-site.example.com/posts.json" \
-H "Api-Key: YOUR_API_KEY" \
-H "Api-Username: YOUR_USERNAME" \
--data-urlencode "title=API timing test" \
--data-urlencode "raw=Small plain text API test post" \
--data-urlencode "category=1"
إذا ظهر التحذير مرة أخرى، فسيكون من المفيد مقارنة ما يلي:
- قيمة
time_totalمن جانب العميل؛ - ما إذا كان يحدث فقط أحيانًا أم في كل منشور عبر API؛
- ما إذا كان يحدث بعد إعادة التشغيل/إعادة البناء، أم أثناء التشغيل العادي؛
- ما إذا كان هناك عدة طلبات API تُنفَّذ متقاربة زمنيًا؛
- ما إذا كان استدعاء API نفسه ينشئ المنشور بنجاح مرة واحدة فقط.
في هذه المرحلة، لا يزال الأمر يبدو وكأنه تحذير ناتج عن مسار إنشاء المنشور عبر API يستغرق وقتًا أطول من نافذة القفل المؤقتة (mutex) القصيرة، وليس دليلًا على فشل المنشور أو مشكلة المنشورات المكررة.