C’è stato un errore nel mio aggiornamento
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
Per favore aiutami a correggerlo.
Sembra che tu abbia installato il plugin, ma non hai eseguito le migrazioni per creare le tabelle necessarie che utilizza.
Puoi mostrarci la parte della definizione del contenitore in cui lo installi?
Grazie, ma discourse-workflows non è qualcosa che ho installato; è un plugin principale integrato (incluso in plugins/, sviluppato da Discourse, attivato tramite enable_discourse_workflows), quindi non c’è nulla relativo ad esso nel mio file app.yml.
La tabella ha una riga di migrazione alla linea 212 di db/migrate/20260312000000_create_workflow_tables.rb che crea discourse_workflows_webhooks, ma non è mai stata eseguita sul mio database.
Pubblico principalmente nel caso in cui valga la pena aggiungere una protezione a quel lavoro pianificato (PurgeExpiredWebhookTestListeners), in modo che una tabella mancante venga gestita in modo silenzioso invece di generare un errore ad ogni esecuzione.
1 Mi Piace
La tabella discourse_workflows_webhooks ha effettivamente una migrazione che la crea (create_workflow_tables, versione 20260312000000, il comando create_table si trova verso la fine di quel file).
Nel mio database, tale migrazione è già registrata come eseguita in schema_migrations, ma la tabella dei webhook non è mai stata creata.
Un’esecuzione pulita di db:migrate lo ha confermato: è stata eseguita senza produrre output, quindi non c’era nulla in attesa, eppure la tabella continuava a non esistere. Rails si basa sul numero di versione, vede la migrazione come completata e non la esegue di nuovo, così la tabella rimane assente mentre il modello e il job di pulizia pianificato continuano a caricarsi ed essere eseguiti. Ecco perché lo stesso errore del job continuava ad accumularsi.
La soluzione applicata: poiché la migrazione era già registrata, non era possibile eseguirla di nuovo, perché avrebbe tentato di ricreare le altre tabelle dei workflow che esistevano già e sarebbe fallita.
Quindi ho creato direttamente la tabella mancante, facendo corrispondere esattamente la migrazione (stesse colonne, stessi cinque indici incluso quello unico):
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
Dopo questo intervento, table_exists? restituisce true e il job PurgeExpiredWebhookTestListeners smette di generare errori alla sua prossima esecuzione.
Poiché questo problema derivava dall’aver modificato una migrazione già distribuita dopo che era stata eseguita, un futuro aggiornamento del core che aggiunge una migrazione corretta per questa tabella potrebbe tentare di crearla di nuovo e fallire con l’errore “già esistente”.
Se ciò dovesse verificarsi dopo un aggiornamento, la soluzione è lasciare che prevalga la nuova migrazione: eliminare prima la tabella creata manualmente oppure inserire la sua versione in schema_migrations in modo che venga ignorata.
Segnalo il problema nel caso qualcuno sulla branch più recente si imbattesse nello stesso errore del job.
1 Mi Piace