أصدرت Langfuse الإصدار v4.25.0 في 31 أغسطس عند الساعة 10:42:43 UTC. ويقدّم هذا الإصدار حدًّا للاحتفاظ يقيّد مدى رجوع الاستعلام: 30 يومًا على فئة Cloud Hobby و90 يومًا على Core. ويُطبَّق هذا الحد عبر نحو اثني عشر من نهايات REST وست أدوات MCP. ويُصنَّف طلب السحب على أنه إصلاح خلل، غير كاسر.
لماذا هذا التصنيف غير صحيح في ظاهره
واجهة API كانت تُرجع 180 يومًا من التتبعات أمس وتُرجع 30 يومًا اليوم قد غيّرت عقدها. لا شيء في الطلب غير صالح؛ إنما الردّ جرى اقتطاعه فقط. أي لوحة معلومات أو تقرير مجدول أو مهمة تقييم تحسب رقمًا ربع سنويًا تستمر في العمل، وتستمر في إرجاع 200، وتبدأ في إنتاج إجابة مختلفة. إن تغييرًا يبدّل النتائج من دون أن يبدّل رموز الحالة هو أغلى أنواع التغييرات التي يمكن وصفها بأنها غير كاسرة، لأن لا شيء في المنظومة اللاحقة يستطيع رصده.
الإشارة التي جرى حسابها ثم التخلص منها
يعرف التنفيذ متى يكون قد اقتطع الاستعلام — فهو يحسب راية تشير إلى أن النطاق قد جرى تقييده. لكن هذه الراية لا تُعرَض. فلا تتحول إلى ترويسة استجابة، ولا إلى حقل في الحمولة، ولا إلى تحذير. وبذلك يمتلك الخادم المعلومة الدقيقة التي يحتاجها العميل لمعرفة أن بياناته غير مكتملة، ثم يتخلص منها قبل الرد. وكان من الممكن لإضافة ترويسة واحدة أن تحوّل الاقتطاع الصامت إلى اقتطاع يمكن اكتشافه، تقريبًا من دون كلفة.
ما الذي يخطئ فيه التأطير الشائع
حدود الاحتفاظ في الفئات المجانية أمر اعتيادي ومبرّر؛ فلدى الخدمة المستضافة الحق في تحديد ما تخزنه وتقدمه. القضية ليست أن Langfuse فرضت حدًا، بل في كيفية تقديم هذا الحد: على أنه قيد صامت غير معلن، وموسوم بأنه غير كاسر، على نهايات يعتمد عليها مستهلكون آليون. وإذا قرأت ذلك على أنه "فئة مجانية تحصل على احتفاظ لمدة 30 يومًا"، فهو تفصيل تسعيري. أما إذا قرأته على أنه "بدأت اثنتا عشرة نهاية تعيد بيانات أقل من دون إشعار"، فهو إخفاق في الرصد داخل منتج للرصد.
ما الذي ينبغي التحقق منه
أي مقياس يعتمد على Langfuse ويمتد لأكثر من 30 يومًا على Hobby أو 90 يومًا على Core ينبغي إعادة اشتقاقه بعد الترقية. لن يظهر خطأ. لكنه سيصبح أصغر فحسب، وسيبدو الفرق أشبه بانخفاض في الزيارات لا بانخفاض في الرؤية.