لقد حدث خطأ في تحديثاتي
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
الرجاء مساعدتي في إصلاحه.
يبدو أنك قمت بتثبيت الإضافة، لكنك لم تشغّل عمليات الترحيل (migrations) لإنشاء الجداول اللازمة التي تستخدمها.
هل يمكنك إظهارنا الجزء من تعريف الحاوية (container definition) حيث تقوم بتثبيتها؟
شكرًا لك، لكن discourse-workflows ليس شيئًا قمت بتثبيته؛ إنه ملحق أساسي مدمج (يُوزع ضمن مجلد plugins/، وكتبته Discourse، ويُفعّل عبر enable_discourse_workflows)، لذا لا يوجد أي شيء متعلق به في ملف app.yml الخاص بي.
يحتوي الجدول على سطر هجرة في السطر 212 من ملف db/migrate/20260312000000_create_workflow_tables.rb الذي ينشئ discourse_workflows_webhooks، لكنه لم يُنفَّذ على قاعدة بياناتي.
أشارك هذا التعليق بشكل أساسي في حال كان من الجيد إضافة شرط حماية لذلك المهمة المجدولة (PurgeExpiredWebhookTestListeners) بحيث يتعامل النظام بهدوء مع غياب الجدول بدلاً من إظهار خطأ في كل تشغيل.
إعجاب واحد (1)
يحتوي الجدول discourse_workflows_webhooks بالفعل على هجرة (migration) تنشئه (create_workflow_tables، الإصدار 20260312000000، حيث تقع أمر create_table بالقرب من أسفل ذلك الملف).
في قاعدة بياناتي، تم تسجيل تنفيذ هذه الهجرة بالفعل في schema_migrations، لكن جدول الويب هوكس (webhooks) نفسه لم يتم إنشاؤه مطلقًا.
أكدت عملية db:migrate نظيفة ذلك: لقد تم تنفيذها دون أي إخراج، مما يعني أنه لا يوجد أي شيء معلق، ومع ذلك فإن الجدول لا يزال غير موجود. يعتمد Rails على رقم الإصدار، ويرى أن الهجرة مكتملة، ولا ينفذها مرة أخرى، لذلك يبقى الجدول مفقودًا بينما يستمر النموذج (model) ومهمة التنظيف المجدولة في التحميل والتشغيل. هذا هو السبب في أن نفس استثناء المهمة كان يتراكم.
الحل الذي طبقته: نظرًا لأن الهجرة مسجلة، لم يكن إعادة تشغيلها خيارًا متاحًا، لأنها كانت ستحاول إعادة إنشاء جداول سير العمل الأخرى الموجودة بالفعل وستفشل.
لذلك، قمت بإنشاء الجدول المفقود مباشرة، مطابقًا للهجرة تمامًا (نفس الأعمدة، ونفس الفهارس الخمسة بما في ذلك الفهرس الفريد):
conn = ActiveRecord::Base.connection
unless conn.table_exists?(:discourse_workflows_webhooks)
conn.create_table :discourse_workflows_webhooks do |t|
t.bigint :workflow_id, null: false
t.string :workflow_version_id, limit: 36
t.string :node_name, null: false, limit: 100
t.string :webhook_path, null: false, limit: 500
t.string :http_method, null: false, limit: 10
t.string :webhook_id, limit: 36
t.integer :path_length
t.boolean :test_webhook, null: false, default: false
t.integer :user_id
t.jsonb :workflow_snapshot
t.datetime :expires_at
t.datetime :created_at, null: false, default: -> { "CURRENT_TIMESTAMP" }
end
conn.add_index :discourse_workflows_webhooks, %i[http_method webhook_path test_webhook], unique: true, name: "idx_dwf_webhooks_on_method_path_test"
conn.add_index :discourse_workflows_webhooks, %i[webhook_id http_method test_webhook], name: "idx_dwf_webhooks_on_webhook_id_method_test", where: "webhook_id IS NOT NULL"
conn.add_index :discourse_workflows_webhooks, :workflow_id, name: "idx_dwf_webhooks_on_workflow_id"
conn.add_index :discourse_workflows_webhooks, :workflow_version_id, name: "idx_dwf_webhooks_on_workflow_version_id"
conn.add_index :discourse_workflows_webhooks, :expires_at, name: "idx_dwf_webhooks_on_expires_at", where: "expires_at IS NOT NULL"
end
بعد ذلك، ترجع table_exists? بقيمة true، وتتوقف مهمة PurgeExpiredWebhookTestListeners عن إظهار الأخطاء في تشغيلها التالي.
نظرًا لأن هذا ناتج عن تعديل هجرة تم إصدارها بعد تنفيذها بالفعل، فقد تحاول تحديث أساسي لاحق يضيف هجرة صحيحة لهذا الجدول إنشاؤه مرة أخرى وتفشل بـ “موجود بالفعل”.
إذا ظهر ذلك بعد التحديث، فإن الحل هو السماح للهجرة الجديدة بالفوز: احذف الجدول الذي أنشأته يدويًا أولاً، أو أدخل إصداره في schema_migrations ليتم تخطيه.
أشير إلى هذه الحالة في حال واجه أي شخص آخر على الفرع الرئيسي نفسه نفس استثناء المهمة.
3 إعجابات