أعاد Nano Banana Pro خطأ خادم قبل أن يولد أي شيء

Higgsfield API error (HTTP 500). Internal Server Error

أعاد Nano Banana Pro هذه الرسالة على الفور. لم ينشئ مهمة، ولم يولد أي صورة.

كان الأمر الفاشل يستخدم nano_banana_2 مع صورة مرجعية، و--aspect_ratio auto، و--resolution 4k. وتكرر الفشل نفسه سواء قدمت مسارا محليا أو معرف رفع.

كان الشك البديهي يتجه إلى ملف المرجع. لكن ذلك لم يكن سوى جزء من المشكلة.

كانت هناك مشكلتان منفصلتان في المعاملات تنتجان رد الخادم نفسه، الذي لا يفيد بشيء.

auto مسموح على الورق ومعطل في الواقع

كان مخطط النموذج يدرج auto ضمن القيم المقبولة لـaspect_ratio. ومع ذلك تسبب تمريرها في خطأ HTTP 500.

لهذا أهميته، لأن قيمة مدرجة في قائمة القيم المسموحة تبدو عادة أكثر أمانا من نسبة يختارها المرء يدويا. توقعت أن يفحص الخادم الصورة المصدر ويختار بنفسه. لكن الطلب فشل قبل إنشاء أي مهمة.

أما المشكلة الثانية فكانت في الخيار --image. فهذا الخيار أيضا كان ينتج خطأ 500 مع هذا النموذج.

كان Nano Banana Pro يتوقع المرجع عبر input_images. ولم يكن يكفي نقل معرف الرفع إلى مصفوفة. فالمصفوفة كانت تحتاج إلى كائنات بشكل محدد:

[
  {
    "id": "<upload-id>",
    "type": "media_input"
  }
]

فشلت مصفوفة من النصوص بالرسالة Input should be a valid object. وفشل كائن يحتوي على المعرف من دون النوع بالرسالة Field required.

كانت رسائل التحقق هذه أنفع من خطأ 500 الأصلي. فقد أظهرت أن الخادم لا يحتاج إلى صورة مرفوعة فحسب، بل إلى مدخل وسائط منظم.

صغرت الطلب قبل أن أجرب 4K من جديد

لم أواصل إعادة إرسال أمر التكبير الكامل. بنيت اختبارا أدنى بدقة 1K.

أولا، رفعت الصورة الأصلية:

higgsfield upload create <path> --json

أعاد ذلك معرف الرفع الذي يحتاج إليه input_images.

بعد ذلك، تحققت من أبعاد الصورة المصدر باستخدام PIL:

python -c "from PIL import Image; print(Image.open(p).size)"

بعد أن عرفت الأبعاد، اخترت أقرب نسبة صريحة يدعمها النموذج. وفي هذه الحالة انطبقت على الصورتين الأصليتين النسبتان 2:3 و4:3.

لم أمرر auto.

ثم وضعت كائن الوسائط في ملف JSON ومررته عبر:

--input_images @file.json

استخدم الاختبار دقة 1K حتى أتحقق من شكل الطلب قبل الالتزام بالنتيجة الحقيقية. وعندما أنشأ ذلك الطلب مهمة وأكملها، استخدمت البنية نفسها في عمليات 4K.

اكتملت عمليتا التكبير بدقة 4K. وجرى التحقق من ذلك في 11 يونيو 2026.

لماذا كان الاختبار الأدنى مهما

فشلت عمليات التكبير الأصلية ثلاث مرات مع الجمع بين --image وauto. ولم يكشف تكرار ذلك الأمر ما إذا كانت المسؤولية تقع على الصورة أو النسبة أو الدقة أو بنية الطلب.

أما الاختبار الصغير ففصل بين هذه المتغيرات.

حددت رسائل التحقق بنية الكائن المطلوبة. وأزالت النسب الصريحة القيمة المعطلة auto. ولم أعد إلى دقة 4K المقصودة إلا بعد أن نجح التعديلان معا بدقة 1K.

كانت التكلفة الإضافية اختبارا واحدا بدقة 1K.

لم يكن هناك داع لاختبار 8K. فالحد الأقصى لكل من Nano Banana Pro وBytedance Image Upscale على المنصة هو 4K.

تحقق مما إذا كان الطلب الفاشل قد صار مهمة

قد يبدو خطأ HTTP 500 الفوري مكلفا لأنه يصل من الواجهة البرمجية لا من التحقق المحلي. وفي هذه الحالة حدث الفشل قبل إنشاء المهمة ولم يستهلك أي رصيد.

ومع ذلك أتحقق من هذا بدل أن أفترضه.

بعد خطأ 500 فوري، أفحص:

higgsfield generate list

إذا لم تنشأ أي مهمة، أعرف أن الطلب فشل قبل دخوله طابور التوليد. وهذا يفصل الطلب المشوه عن نتيجة مولدة فشلت لاحقا.

ويغير ذلك أيضا طريقة تصحيحي للخطأ. فخطأ 500 السابق للإنشاء يستدعي فحص المعاملات، ولا يستدعي محاولة أخرى بالدقة الكاملة وبالمعاملات نفسها.

القاعدة التي أعمل بها الآن

مع nano_banana_2، لا أستخدم أبدا --aspect_ratio auto. أفحص أبعاد المصدر وأختار أقرب نسبة صريحة مدعومة.

وأمرر المراجع أيضا عبر input_images في صورة مصفوفة من الكائنات. يتضمن كل كائن معرف الرفع و"type": "media_input" معا.

قبل أي دفعة مدفوعة، أرسل طلبا أدنى واحدا بدقة 1K. يؤكد هذا الاختبار شكل الوسائط والنسبة ومسار إنشاء المهمة بأصغر اختبار موثق.

إذا كان Nano Banana Pro يعيد لك اليوم خطأ 500 فوريا، فافحص قائمة المهام أولا. ثم استبدل auto، وتوقف عن استخدام --image، وجرب طلبا واحدا منظما عبر input_images بدقة 1K.

---

كل حل في هذا المقال سبقه خطأ دفعت ثمنه. الأفضل أن يحدث في فيلمي لا في علامتك التجارية.