「既存トピックに移動」の検索がサイレントに失敗するが、サイト内検索は機能する

こんにちは。

**「既存トピックに移動」**モーダルで問題が発生しています(以前はサイトで機能していたため、リグレッションのようです)。

  • トピックを検索に入力しても結果が絞り込まれない
  • ネットワークリクエストは正しいパラメータで200を返す
  • ブラウザのコンソールにJSエラーはない
  • サイト全体の /search は期待どおりに動作する
  • リビルド後も問題は継続している

行われているリクエストの例:
/search/query?term=Eve Park&type_filter=topic&search_for_id=true&restrict_to_archetype=regular

選択リストは静的なトピックのセットのままで、term が変更されても変化しないようです。


クライアント側のデバッグを行った後、最初はこれがPostgresで pg_trgm が有効になっていないことが原因ではないかと疑いましたが、進む前に確認したいと思いました。

以下のコマンドを実行しました。

./launcher enter app
rails c
ActiveRecord::Base.connection.execute(
  "SELECT extname FROM pg_extension WHERE extname = 'pg_trgm';"
).to_a

この診断は、コマンドが以下を返した場合に有効になります。

[]

しかし、代わりに以下が返されました。

[{"extname"=>"pg_trgm"}]

したがって、pg_trgm有効であり、これが根本原因ではないようです。


そのため、以下のコマンドを実行する予定です。

./launcher enter app
rake search:reindex

私のフォーラムの特定のカテゴリには非常に多くのトピックがあるため、これは関連性があるかもしれません。


混乱しているのは以下の点です。

  • Discourseはそれ以外は正常に機能し続けている
  • 完全な /search は期待どおりに動作する
  • トピック移動のオートコンプリートは警告なしに静かに劣化する

デバッグの一環として、search prefer recent posts 設定を有効にしてブラウザをリロードしました。これは動作に影響を与えませんでした。「既存トピックに移動」の検索は、入力しても結果を絞り込みません。

この設定は完全な /search のランキングにのみ影響し、トピック選択のエンドポイントには影響しないため、問題が一般的な検索パフォーマンスではなく /search/query に特有のものであるという見解と一致しています。


rake search:reindex を実行する前に、理由を再確認したいと思いました。

トピック移動の選択ツールは、search_for_id=true を使用して /search/query を利用します。これは完全な /search エンドポイントよりもインデックス検索に直接依存しています。したがって、部分的に古くなっているか一貫性のない検索インデックスが、完全な検索がまだ動作しているように見えても、選択ツールに影響を与える可能性があります。

以下の点を考慮すると:

  • エンドポイントは呼び出されている
  • レスポンスは200を返す
  • pg_trgm は有効になっている
  • search prefer recent posts の切り替えは効果がない

完全な rake search:reindex が、インデックスの一貫性の問題を排除するための次の論理的なステップのように思われます。別途、警告やフィードバックが全くないことは、管理者UXの観点から特に混乱を招きます。

「いいね!」 1

私の経験では、その検索はこれまで信頼できるものではありませんでした。例えば、こちらのレポートもあります:https://meta.discourse.org/t/topic-cant-be-found-when-searching-for-a-topic-verbatim-when-moving-a-post/308350。
私は通常、トピックIDを入力し、サイトの検索機能を使ってそれを見つけます。

「いいね!」 1

ありがとうございます。参考になる背景情報で、リンクされたレポートも非常によく似ています。

私のケースで奇妙なのは、私が元の投稿(OP)を書いたときには、それが「応答しない」動作をしていたことです。/search/queryterm=Eve Park などで呼び出され(200応答)、チョイスリストは静的なままで全く絞り込まれませんでした。

それ以来、別のブラウザウィンドウと並行して、意図された「応答性の高い検索」動作(セーフモードの録画で示したもの)を再現できるようになりました。

OPで説明したこと以外、サーバー側で何も変更していないため、私の現在の疑いは、最初に以下のいずれかに遭遇したということです。

  • クライアント側の状態の問題(キャッシュされたアセット / ハードリフレッシュの違い / テーマコンポーネントの相互作用)
  • 特定の用語が期待どおりに返されないクエリの境界条件(完全一致 / 句読点 / ストップワード / 順序付け)。リンクされた「完全一致の移動検索ではトピックが見つからない」レポートに似ています。

次に、同じ用語で「応答しない」ケースと「応答性の高い」ケースの /search/query からの実際のJSON応答を比較する予定です。また、テーマあり/なしでセーフモードを再度実行し、それが相関するかどうかを確認します。

移動トピックチョイス(完全な /search とは異なる)で使用される正確なマッチングルール、またはそれが異なる場所を誰か知っていれば、非常に役立ちます。これが既知の制限/境界条件なのか、それともリグレッションなのかを特定しようとしています。