I believe I have found a bug with the wildcard expansion in tag search. Examples in Stack Overflow but are likely applicable on other sites:

Working: Searching for [python-2.7] -[python*] shows no results. That is correct - I'm searching for anything tagged python-2.7 but excluding python* which also excludes python-2.7. Thus nothing remains.

Working: Searching for [python-3.10] -[python*] shows 158 results.

This is because the search term [python*] only expands to (formatted as list for better readability):

  1. -[python]
  2. -[python-3.x]
  3. -[python-2.7]
  4. -[python-requests]
  5. -[python-imaging-library]
  6. -[python-asyncio]
  7. -[python-3.6]
  8. -[python-import]
  9. -[python-multiprocessing]
  10. -[python-3.7]
  11. -[python-multithreading]
  12. -[python-sphinx]
  13. -[python-3.5]
  14. -[python-unittest]
  15. -[python-2.x]
  16. -[python-3.4]
  17. -[python-decorators]
  18. -[python-3.8]
  19. -[python-module]
  20. -[python-xarray]

The expansion does not include [python-3.10], nor [python-3.9]. I am not sure if [python*] is missing other tags. Nor do I know if other tags have a similar problem - as can be seen, searching cannot be relied upon to find tags with such problems.

The same happens when using regular search, rather than tag search: some text -[python*] still does not expand to cover [python-3.10] or [python-3.9]

Note that this is not a problem with limited search string space. Using two tags with wildcards, for example:

both expand fully to the search term:

[python] -[python] -[python-3.x] -[python-2.7] -[python-requests] -[python-imaging-library] -[python-asyncio] -[python-3.6] -[python-import] -[python-multiprocessing] -[python-3.7] -[python-multithreading] -[python-sphinx] -[python-3.5] -[python-unittest] -[python-2.x] -[python-3.4] -[python-decorators] -[python-3.8] -[python-module] -[python-xarray] -[python-datetime] -[ruby-on-rails] -[ruby] -[ruby-on-rails-3] -[ruby-on-rails-4] -[rubygems] -[ruby-on-rails-5] -[ruby-on-rails-3.2] -[ruby-on-rails-3.1] -[ruby-on-rails-6] -[rubymine] -[ruby-on-rails-2] -[ruby-on-rails-plugins] -[ruby-on-rails-4.2] -[rubymotion] -[ruby-on-rails-5.2] -[ruby-1.9.3] -[ruby-2.0] -[ruby-on-rails-4.1] -[ruby-1.9] -[ruby-on-rails-7]

which means it is not a problem with limited search space.

This seems to be a that the wildcard expansion itself has a limit of 20 items. Searching for "python" on the /tags page shows there are at least 27 results:

Screenshot of the results of searching for "python" on the tags page. There are 27 results that start with the term. They are listed following the image.

The list of tags that start with the word "python" are:

  1. [python]
  2. [python-3.x]
  3. [python-2.7]
  4. [python-requests]
  5. [python-imaging-library]
  6. [python-asyncio]
  7. [python-3.6]
  8. [python-import]
  9. [python-multiprocessing]
  10. [python-3.7]
  11. [python-multithreading]
  12. [python-sphinx]
  13. [python-3.5]
  14. [python-unittest]
  15. [python-2.x]
  16. [python-3.4]
  17. [python-decorators]
  18. [python-3.8]
  19. [python-module]
  20. [python-xarray]
  21. [python-datetime]
  22. [python-re]
  23. [python-tesseract]
  24. [python-idle]
  25. [python-typing]
  26. [python-2.6]
  27. [python-docx]

The results still do not include [python-3.10] nor [python-3.9] but that is because they show the top matching tags and those two have less questions associated with them.

Also of note: the first 20 tags from the list match exactly with the 20 tags [python*] expands to. This suggests that the tag expansion is based on the order by popularity.

Please fix wildcards for tags to match all variations. The very reason I (at least) use wildcards is in order to watch out for newer tags created which happens often when the versions are included in the tag name itself. This means that I only need to define few rules or custom filters. This issue can show up in many sites which use some sort of namespacing of tags. For example, on Role-playing Games there are the [dnd*] tags which are not 20 yet (only 14 so far) but would probably eventually reach that. Arquade might also have a similar problems with series and spinoffs. I am not sure but I suspect Science Fiction & Fantasy and/or Physics and/or Biology and/or Mathematics, among others might also have a lot of tags that start with the same or similar text.

  • 3
    Looks like there is indeed hard limit of 20, not documented anywhere, yet. Sep 13 at 13:47
  • I suspected this. But wasn't sure how to find another wildcard that expands to 20+ items. I do suspect that's the case. Which means that making custom filters to catch variations of tags can miss some.
    – VLAZ
    Sep 13 at 13:53
  • You can do the same with [java*] search, more than 20 actual tags, only 20 are expanded. Sep 13 at 13:56
  • 1
    Yep, just checked [c++*] and it expanded to 20 tags, yet searching for tags shows 21 tags that start with "c++"
    – VLAZ
    Sep 13 at 14:09
  • 1
    Nice detective work! :-) Sep 13 at 14:14
  • possibly related: meta.stackexchange.com/questions/346796/…
    – Luuklag
    Sep 13 at 14:20
  • 1
    @Luuklag not related. It's still a bug - you can end up with a search string that's too long and then the search bar becomes unusable until you shorten it. Other than wildcards, another easy way to replicate it is making a custom filter and adding many tags. When the custom filter loads, it also shows the tags in the search bar and it's unusable. However, I do not believe that to be related to the wildcard search, just a separate problem that happens to show up with wildcards (since it generates a very long string).
    – VLAZ
    Sep 13 at 14:26
  • 1
    I did a little digging concerning this with regards to filters a little bit ago. [azure*] references over 220 tags on Stack Overflow, but it will only expand to the top 20 in search. Bear in mind that there's a hard cap for the search URL length; in that post I discovered that search errors out altogether when the URL hits around 2000 characters, so that's another limitation to truly ginormous tag searches. To be fair though, tag search URLs with an inline wildcard resolve without expanding.
    – zcoop98
    Sep 13 at 16:36
  • Possibly by-design for 20 tags hard limit: 400 error from links on wildcard tag searches (2010) Sep 14 at 4:47


You must log in to answer this question.

Browse other questions tagged .