Filtri personalizzati degli argomenti: i parametri URL non raggiungono `TopicQuery.options`

Rapporto di avanzamento finora:

  1. Ho confermato che i metodi di whitelist statica TopicQuery come add_custom_param_handler o extra_options_whitelist non sono disponibili come metodi di classe nella mia versione di Discourse, quindi questi approcci sono stati abbandonati.

  2. Ho implementato una patch per ListController#build_topic_list_options per iniettare i miei parametri URL personalizzati (ad esempio, market_item_statuses, market_price_min) nel dizionario opts prima che venga chiamato TopicQuery.new.

  3. Questa parte ora funziona! Quando effettuo una richiesta come /c/market/5/l/latest.json?filter=defaultmarket_item_statuses=Available, i miei log del server confermano l’iniezione:

    [TecencMarket_ListControllerExt_BuildOptsV3] Iniettato in opts: market_item_statuses = Available
    
    

    Quindi, TopicQuery.new(user, opts) ora riceve opts che contiene i miei parametri personalizzati.

Punto attuale di blocco: errore 500  blocco del filtro non raggiunto

Nonostante i parametri siano ora correttamente passati all’inizializzatore di TopicQuery, ottengo ancora un errore interno del server 500 quando la richiesta include questi parametri di mercato personalizzati.

Per isolare il problema, ho semplificato il mio blocco TopicQuery.add_custom_filter(:"tecenc_market_filters") al minimo assoluto.

# plugin.rb - Blocca filtro personalizzato semplificato attuale
if ::TopicQuery.respond_to?(:add_custom_filter)
  ::TopicQuery.add_custom_filter(:"tecenc_market_filters") do |topics, topic_query|
    topics_originali = topics
    opts = topic_query.options
    log_prefix_query = "[TecencMarket_SimplifiedFilter_V1.1_Test]" # Prefisso di debug

    Rails.logger.info "#{log_prefix_query} Opts ricevuti da TopicQuery: #{opts.inspect}"

    if opts[:market_item_statuses].present?
      Rails.logger.info "#{log_prefix_query} 'market_item_statuses' È PRESENTE in opts: #{opts[:market_item_statuses]}"
    else
      Rails.logger.info "#{log_prefix_query} 'market_item_statuses' NON È PRESENTE in opts."
    end
    
    Rails.logger.info "#{log_prefix_query} Restituisco la relazione degli argomenti originali."
    topics_originali # ritorno implicito
  end
  Rails.logger.info "[TecencMarket] Applicato filtro personalizzato SEMPLIFICATO (V1.1_Test)."
end

Osservazioni con questo filtro semplificato:

  • Richieste senza il mio parametro di filtro personalizzato (es., /c/market/5/l/latest.json?filter=default):

    • Il blocco di filtro semplificato registra correttamente:

      [TecencMarket_SimplifiedFilter_V1.1_Test] Opts ricevuti da TopicQuery: {:category=>5, :filter=>"default", ...}
      [TecencMarket_SimplifiedFilter_V1.1_Test] 'market_item_statuses' NON È PRESENTE in opts.
      [TecencMarket_SimplifiedFilter_V1.1_Test] Restituisco la relazione degli argomenti originali.
      
      
    • La pagina si carica con un 200 OK.

  • Richieste con il mio parametro di filtro personalizzato (es., /c/market/5/l/latest.json?filter=defaultmarket_item_statuses=Available):

    • L’output di log del ListController appare: [TecencMarket_ListControllerExt_BuildOptsV3] Injected into opts: market_item_statuses = Available

    • Si verifica un Completed 500 Internal Server Error in ...ms immediatamente dopo.

    • ** Fondamentalmente, NESSUN log proveniente dal blocco filtrante semplificato (senza le linee [TecencMarket_SimplifiedFilter_V1.1_Test]...) compare per questa richiesta fallita.**

Questo indica che l’errore 500 avviene dopo l’inizializzazione di TopicQuery con il hash opts (che ora contiene i miei parametri personalizzati), ma prima o proprio mentre il meccanismo centrale di Discourse TopicQuery#apply_custom_filters tenta di eseguire il mio blocco di filtro registrato (e ora estremamente semplice).

Ho difficoltà a isolare l’eccezione Ruby specifica e il backtrace completo da development.log che precede immediatamente la linea “Completed 500…” per le richieste fallite (gli estratti di log che ho raccolto mostrano solo la linea 500, ma non il messaggio di errore dettagliato appena prima).

Domanda di follow-up:

Considerando che:

  1. I parametri personalizzati vengono ora iniettati con successo in TopicQuery.options tramite la patch del ListController.

  2. Si verifica un errore 500 quando questi parametri personalizzati sono presenti in opts.

  3. Questo errore 500 avviene prima che il blocco di filtro personalizzato estremamente semplificato (che si limita a loggare e restituire la relazione originale) venga eseguito con la sua prima riga di codice per la richiesta con parametri personalizzati.

  4. È su Discourse 3.5.0.beta3-dev.

Cosa potrebbe causare che TopicQuery stesso, o il suo metodo apply_custom_filters, generino un errore prima di invocare un filtro personalizzato registrato, specificamente quando il hash options contiene queste chiavi specifiche del plugin? La precedente LocalJumpError che sospettavamo potrebbe ancora essere rilevante a un livello più basso nel modo in cui apply_custom_filters gestisce l’iterazione o la chiamata ai blocchi di filtro, anche se il mio blocco semplificato è solo un ritorno implicito?

Qualsiasi guida su cosa verificare successivamente nel comportamento di TopicQuery con questi tipi di opzioni personalizzate, o consigli su come ottenere in modo affidabile il backtrace completo per l’errore 500 in questa situazione, sarebbe estremamente utile.