Pinned hashtag search has hidden limit of 4 search terms

[jgoerzen]

Expected behaviour

Hi,

On a Mastodon 3.2.1 instance, I did a search for a hashtag. Using the advanced web interface, I pinned it to a column, ticked "Include additional tags for this column", and added about a dozen to the "any of these" category. The goal being to be able to follow content from around the Fediverse on certain topics.

I actually did this for two different groups of tags: one centered around Linux topics, and the other on everything else.

Actual behaviour

It doesn't properly reflect the tags. For instance, here's what my "everything else" looks like:

Notice that #COVID is included in the list. If I do a standalone search for #COVID, I see this:

Notice that the standalone search for COVID shows things from within the past hour, but the more broad search doesn't show anything at all more recent than 2 days old.

I tried adding #COVID to the tech search, and that didn't help either. I tried refreshing and reloading -- no dice. I tried removing and re-adding it from that column -- also no good.

Eventually I discovered that only the first four tags in "any of these" are processed. If #COVID was within the first four, it was processed. If not, ignored.

Steps to reproduce the problem

See above

Specifications

Mastodon v3.2.1

Firefox 82.0.3 on Linux

[jgoerzen]

I first learned about this feature in this conversation about #8904. Also, I have replicated this issue on both floss.social and mastodon.online. Additionally, I replicated the same behavior with the Tusky Android client, which leads me to believe it's not an issue with the FE UI at least (or, if this is a known limitation, it's an issue that the FE UIs allow people to enter search terms that will be silently ignored)

[jgoerzen]

It looks like this behavior was introduced in September 2020 by e8bc187 in PR #14728 :

Near the top of app/models/tag_feed.rb:

LIMIT_PER_MODE = 4

I would argue this const should go away. It prevents a very useful pattern.

If it is retained, it needs to be documented and plumbed through the API and to the UI, because right now Mastodon will just silently ignore search terms:

  def tags_for(names)
    Tag.matching_name(Array(names).take(LIMIT_PER_MODE)).pluck(:id) if names.present?
  end

[connyduck]

I'd like to know if this is going to be fixed or if we should limit the number of hashtags to 4 in Tusky. Right now this is unacceptable.

[Gargron]

Every hashtag in the and/or query makes it go slower, so the limit is intended to reduce strain on the server.

Unless the method by which posts are retrieved is changed, I don't see the limit going away.

The limit not being communicated in the UI is an oversight, though.

[aspensmonster]

Just chiming in that I really like the idea of tag collection columns too. Presently, I instead have quite a few separate columns defined in order to work around this limit, rather than a handful with collections. I suspect that such an approach isn't much better performance-wise either.

Is there a particular place I could start digging first to see what we could do about performance concerns with complex queries? Any previous discussions on the matter?

[claudeha]

Every hashtag in the and/or query makes it go slower, so the limit is intended to reduce strain on the server.

Is one query with tagA or tagB really slower than two queries for tagA, tagB separately? Because that's the workaround that people will end up using (adding multiple columns in the web UI. for example).

[ronilaukkarinen]

This is still an issue on 4.1.4.