“Move to existing topic” search silently fails while site search still works

Bug
, , ,
1

Hi,

I’m seeing an issue with the “Move to existing topic” modal (this previously worked on my site, so appears to be a regression):

  • Typing in Search for a Topic does not refine results
  • Network requests return 200 with correct parameters
  • No JS errors in the browser console
  • Whole-site /search works as expected
  • The issue has persisted across rebuilds

Example request being made:
/search/query?term=Eve Park&type_filter=topic&search_for_id=true&restrict_to_archetype=regular

The chooser list appears to remain a static set of topics and does not change as the term changes.

After client-side debugging, I initially suspected this might be caused by pg_trgm not being enabled in Postgres, but wanted to confirm this before proceeding.

I ran the following commands:

./launcher enter app
rails c

ActiveRecord::Base.connection.execute(
  "SELECT extname FROM pg_extension WHERE extname = 'pg_trgm';"
).to_a

This diagnosis would be valid if the command returned:

[]

However, instead it returned:

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

So pg_trgm is enabled, and this does not appear to be the root cause.

I therefore intend to run the following command:

./launcher enter app
rake search:reindex

This may be relevant because a particular category of my forum has a very large number of topics.

What’s confusing is that:

  • Discourse otherwise continues to function normally
  • Full /search works as expected
  • The topic-move autocomplete silently degrades instead of warning

As part of debugging, I also enabled the search prefer recent posts setting and reloaded the browser. This had no effect on the behaviour - the “Move to existing topic” search still does not refine results as I type.

Since that setting only affects full /search ranking and not the topic chooser endpoint, this seems consistent with the issue being specific to /search/query rather than general search performance.

Before running rake search:reindex, I wanted to sanity-check the reasoning:

The topic-move chooser uses /search/query with search_for_id=true, which relies more directly on indexed lookups than the full /search endpoint. A partially stale or inconsistent search index could therefore affect the chooser while full search still appears to work.

Given that:

  • the endpoint is being called,
  • responses return 200,
  • pg_trgm is enabled,
  • and toggling search prefer recent posts has no effect,

A full rake search:reindex seems like the next logical step to rule out index inconsistency. Separately, the lack of any warning or feedback makes this particularly confusing from an admin UX perspective.

1 Like
2

3

That search has never been reliable in my experience. For example, there is also this report: Topic can't be found when searching for a topic (verbatim) when moving a post.
I usually enter the topic ID and use the site’s search to find that.

1 Like
4

Thanks - that’s helpful context, and the linked report looks very similar.

What’s odd in my case is that it did behave “non-responsive” when I wrote the OP: /search/query was being called with term=Eve Park etc. (200 responses), but the chooser list stayed static and did not refine at all.

Since then, I can now reproduce the intended “responsive search” behaviour (as shown in my Safe Mode recording) side-by-side with another browser window.

I haven’t changed anything on the server beyond what I described in the OP, so my current suspicion is that I initially hit either:

  • a client-side state issue (cached assets / hard refresh difference / theme component interaction), or
  • a query edge case where certain terms don’t return as expected (verbatim / punctuation / stop words / ordering), similar to the “verbatim move search can’t find topic” report you linked.

Next I’m going to compare the actual JSON response from /search/query between the “non-responsive” case and the “responsive” case (same term), and I’ll also run Safe Mode again with/without themes to see if it correlates.

If anyone knows the exact matching rules used by the move-topic chooser (vs full /search) or where it differs, that would be super helpful - I’m trying to pin down whether this is a known limitation/edge case or a regression.