Benutzerdefinierte Themenfilter: URL-Parameter erreichen `TopicQuery.options` nicht

Entwickler
3

Bisheriger Fortschrittsbericht:

  1. Bestätigt, dass statische TopicQuery Whitelist-Methoden wie add_custom_param_handler oder extra_options_whitelist in meiner Discourse-Version nicht als Klassenmethoden verfügbar sind, daher wurden diese Ansätze aufgegeben.

  2. Ein Patch für ListController#build_topic_list_options implementiert, um meine benutzerdefinierten URL-Parameter (z. B. market_item_statuses, market_price_min) in die opts-Hash zu injizieren, bevor TopicQuery.new aufgerufen wird.

  3. Dieser Teil funktioniert jetzt! Wenn ich eine Anfrage wie /c/market/5/l/latest.json?filter=defaultmarket_item_statuses=Available stelle, bestätigen meine Server-Logs die Injektion:

    [TecencMarket_ListControllerExt_BuildOptsV3] Injekted into opts: market_item_statuses = Available

    Somit erhält TopicQuery.new(user, opts) jetzt opts, die meine benutzerdefinierten Parameter enthalten.

Aktueller Engpass: 500 Fehler & Filter-Block wird nicht erreicht

Trotzdem, dass die Parameter jetzt korrekt an den Initializer von TopicQuery übergeben werden, erhalte ich immer noch einen 500 Internal Server Error, wenn die Anfrage diese benutzerdefinierten Marktparameter enthält.

Um das zu isolieren, habe ich meinen TopicQuery.add_custom_filter(:"tecenc_market_filters")-Block auf das absolut Minimum reduziert.

# plugin.rb - Aktueller vereinfachter benutzerdefinierter Filterblock
if ::TopicQuery.respond_to?(:add_custom_filter)
  ::TopicQuery.add_custom_filter(:"tecenc_market_filters") do |topics, topic_query|
    original_topics_relation = topics 
    opts = topic_query.options
    log_prefix_query = "[TecencMarket_SimplifiedFilter_V1.1_Test]" # Mein Debug-Prefix

    Rails.logger.info "#{log_prefix_query} Opts empfangen von TopicQuery: #{opts.inspect}"

    if opts[:market_item_statuses].present?
      Rails.logger.info "#{log_prefix_query} 'market_item_statuses' IST VORHANDEN in opts: #{opts[:market_item_statuses]}"
    else
      Rails.logger.info "#{log_prefix_query} 'market_item_statuses' IST NICHT VORHANDEN in opts."
    end
    
    Rails.logger.info "#{log_prefix_query} Rückgabe der ursprünglichen Topics-Relation."
    original_topics_relation # Implizite Rückgabe
  end
  Rails.logger.info "[TecencMarket] Angewandter vereinfachter Filter (V1.1_Test)."
end

Beobachtungen mit diesem vereinfachten Filter:

  • Anfragen ohne meinen benutzerdefinierten Filterparameter (z. B. /c/market/5/l/latest.json?filter=default):

    • Der vereinfachte Filter-Block protokolliert korrekt:

      [TecencMarket_SimplifiedFilter_V1.1_Test] Opts empfangen von TopicQuery: {:category=>5, :filter=>"default", ...}
[TecencMarket_SimplifiedFilter_V1.1_Test] 'market_item_statuses' IST NICHT VORHANDEN in opts.
[TecencMarket_SimplifiedFilter_V1.1_Test] Rückgabe der ursprünglichen Topics-Relation.

    • Die Seite lädt mit einem 200 OK.

  • Anfragen mit meinem benutzerdefinierten Filterparameter (z. B. /c/market/5/l/latest.json?filter=defaultmarket_item_statuses=Available):

    • Das Log des ListController-Patches erscheint: [TecencMarket_ListControllerExt_BuildOptsV3] Injected into opts: market_item_statuses = Available

    • Ein Completed 500 Internal Server Error in ...ms tritt sofort danach auf.

    • Wichtig ist, dass KEINE Logs aus dem vereinfachten Filterblock erscheinen (keine [TecencMarket_SimplifiedFilter_V1.1_Test]... Zeilen) für diese fehlerhafte Anfrage.

Dies deutet darauf hin, dass der 500-Fehler nachdem TopicQuery mit dem opts-Hash initialisiert wird (der jetzt meine benutzerdefinierten Parameter enthält), aber vor oder unmittelbar beim Versuch, das von Discourse zentrale TopicQuery#apply_custom_filters-Verfahren auszuführen, tritt der Fehler auf.

Ich habe Schwierigkeiten, die spezifische Ruby-Ausnahme und den vollständigen Backtrace aus development.log zu isolieren, die unmittelbar vor der Zeile „Completed 500…“ bei den fehlerhaften Anfragen auftreten (die Log-Auszüge, die ich gesammelt habe, zeigen die 500-Zeile selbst, aber nicht die detaillierte Fehlermeldung davor).

Folgefrage:

Angesichts:

  1. Dass benutzerdefinierte Parameter erfolgreich in TopicQuery.options durch den ListController-Patch injiziert werden.

  2. Dass ein 500-Fehler auftritt, wenn diese benutzerdefinierten Parameter in opts vorhanden sind.

  3. Dass dieser 500-Fehler vor dem Ausführen eines extrem vereinfachten benutzerdefinierten Filterblocks passiert (der nur protokolliert und die ursprüngliche Relation zurückgibt).

  4. Dass dies in Discourse 3.5.0.beta3-dev passiert.

Was könnte dazu führen, dass TopicQuery selbst oder seine Methode apply_custom_filters einen Fehler wirft, noch bevor ein registrierter benutzerdefinierter Filterblock aufgerufen wird, speziell wenn das options-Hash diese plugin-spezifischen Schlüssel enthält? Könnte der vorherige LocalJumpError, den wir vermuteten, noch relevant sein, auch auf einer niedrigeren Ebene, also bei der Handhabung der Iteration oder des Aufrufs der Filterblöcke durch apply_custom_filters, selbst wenn mein vereinfachter Block nur ein implizites return ist?

Jegliche Hinweise darauf, was als Nächstes bei TopicQuery im Umgang mit diesen Arten von benutzerdefinierten Optionen überprüft werden sollte, oder Ratschläge, wie man den vollständigen Backtrace für den 500-Fehler in diesem Szenario möglichst zuverlässig erhält, wären äußerst hilfreich.