Rapporto di avanzamento finora:
-
Ho confermato che i metodi di whitelist statica
TopicQuerycomeadd_custom_param_handleroextra_options_whitelistnon sono disponibili come metodi di classe nella mia versione di Discourse, quindi questi approcci sono stati abbandonati. -
Ho implementato una patch per
ListController#build_topic_list_optionsper iniettare i miei parametri URL personalizzati (ad esempio,market_item_statuses,market_price_min) nel dizionariooptsprima che venga chiamatoTopicQuery.new. -
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 = AvailableQuindi,
TopicQuery.new(user, opts)ora riceveoptsche 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
ListControllerappare:[TecencMarket_ListControllerExt_BuildOptsV3] Injected into opts: market_item_statuses = Available -
Si verifica un
Completed 500 Internal Server Error in ...msimmediatamente 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:
-
I parametri personalizzati vengono ora iniettati con successo in
TopicQuery.optionstramite la patch delListController. -
Si verifica un errore 500 quando questi parametri personalizzati sono presenti in
opts. -
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.
-
È 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.