Warum erhöht diese Indexroute RecordNotFound in der Bereitstellung, funktioniert aber perfekt in der Entwicklung?

Question

In einer Rails-App habe ich eine Indexroute, die in der Entwicklung perfekt funktioniert, aber wenn sie zur Bereitstellung verschoben wird, wird ein ActiveRecord::RecordNotFound Fehler angezeigt.

Ich habe Probleme, eine systematische Möglichkeit zu finden, dies zu debuggen, weil (a) ich nicht verstehe, warum ein Index RecordNotFound auslösen würde; (b) die Route funktioniert perfekt in der Entwicklung; und (c) Ich bin unsicher, wo ich nach nützlichen Logs/Berichten suchen sollte, um zu sehen, was passiert.

Die Route in Frage:

#routes.rb 
namespace :api, defaults: {format: 'json'} do 
    scope module: :v2, constraints: ApiConstraints.new(version: 2, default: :true) do 
    resources :states 
    end 
end 

In Entwicklung navigierenden zu /api/states trifft die api/v2/Staaten Controller und gibt den richtigen Ausgang.

Im Einsatz die gleiche URL trifft

#application_controller.rb 
rescue_from ActiveRecord::RecordNotFound, with: :record_not_found 

habe ich versucht, einige Debug-Code hinzufügen

api_states_controller

def index 
    Rails.logger.info @states 
    # ..... 
end 

Aber natürlich diese Aktion nicht in Einsatz getroffen wird.

Ich habe auch versucht hier alle Variablen Debug-Code zu :record_not_found

def record_not_found 
    Rails.logger.info 'We are here' 
    flash[:alert] = "That page doesn't exist!" 
    redirect_to root_url 
end 

Welche angehoben wird, aber ich habe nicht in der Lage zu finden, das Hinzufügen zur Verfügung, die mir nützlich etwas erzählen.

Warum sollte ein Index in Entwicklung verfügbar sein, aber RecordNotFound in der Bereitstellung erhöhen? Und was ist ein sinnvoller Weg, dieses Problem zu untersuchen?

Protokollausgabe

Processing by Api::V2::StatesController#index as JSON 
    User Load (1.0ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 ORDER BY "users"."id" ASC LIMIT 1 [["id", 681]] 
    Role Load (1.2ms) SELECT "roles".* FROM "roles" INNER JOIN "roles_users" ON "roles"."id" = "roles_users"."role_id" WHERE "roles_users"."user_id" = $1 [["user_id", 681]] 
    State Load (18.3ms) SELECT "states".* FROM "states" WHERE (name ilike '%%') ORDER BY states.name ASC OFFSET 0 
[active_model_serializers] Event Load (1.9ms) SELECT "events".* FROM "events" WHERE "events"."state_id" = $1 [["state_id", 474]] 
[active_model_serializers] Country Load (1.5ms) SELECT "countries".* FROM "countries" INNER JOIN "regions" ON "countries"."id" = "states"."country_id" WHERE "states"."id" = $1 LIMIT 1 [["id", 475]] 

Answer 1

Wie ich unter Frage Bemerkungen erwähnt, müssen Sie sicherstellen, dass alle db-Abfragen einfach gut ausgeführt werden soll.

Und seit Sie von ActiveRecord::RecordNotFound Ausnahme gerettet, könnte das etwas schwer aus dem Protokoll zu sagen, was schief läuft. Zwei Möglichkeiten, um dies zu debuggen:

1). Ich würde vorschlagen, dass Sie dies tun, setzen Sie Rails.logger.info xxx vor irgendwo, die möglicherweise eine DB-Abfrage haben. Sie fragen beispielsweise nach Rollen des Benutzers, nach Zuständen nach übereinstimmenden Namen, nach Zustandsereignissen, nach Ländern. Basierend auf der Protokollausgabe werden 5 Abfragen ausgelöst. Stellen Sie sicher, dass Sie herausfinden, welche Abfrage fehlerhaft ist und warum.

2). Entfernen Sie die rescue_from, und das Protokoll zeigt Ihnen nur, welche Abfrage fehlgeschlagen ist.

Zur Frage selbst, ja, es läuft gut in der Entwicklung, aber da sie verschiedene dbs haben, dann ist das einzige, was möglicherweise falsch ist Daten.

Sie könnten versuchen, eine Verbindung zur Produktionsdatenbank in Ihrer Entwicklungsumgebung und debuggen.