ref(replay/feedback): don't suggest empty tag

[michellewzhang]

resolves JAVASCRIPT-2WH4

before:

Untitled.mov

after:

Screen.Recording.2024-11-06.at.3.52.50.PM.mov

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 8 lines in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
static/app/components/feedback/feedbackSearch.tsx	0.00%	4 Missing ⚠️
static/app/views/replays/list/replaySearchBar.tsx	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #80353      +/-   ##
==========================================
- Coverage   78.33%   77.33%   -1.01%     
==========================================
  Files        7188     7188              
  Lines      317875   317885      +10     
  Branches    43812    43813       +1     
==========================================
- Hits       249018   245822    -3196     
- Misses      62510    65550    +3040     
- Partials     6347     6513     +166     

[aliu39]

We should look into why we're storing empty tags in the first place 🤔🤔

[michellewzhang]

We should look into why we're storing empty tags in the first place 🤔🤔

it's based on most commonly searched values

[billyvg]

I think we should leave it in because it's a valid use case to look for untagged events

[aliu39]

@billyvg oh is searching for os.name="" meant to be the same as searching for replays without the os.name tag?

Just did a search and this replay with os.name=MacOS is returned.

[billyvg]

@billyvg oh is searching for os.name="" meant to be the same as searching for replays without the os.name tag?

Just did a search and this replay with os.name=MacOS is returned.

No, just literal empty string -- though maybe I am making this up and it's not a valid tag value?

[michellewzhang]

@billyvg oh is searching for os.name="" meant to be the same as searching for replays without the os.name tag?
Just did a search and this replay with os.name=MacOS is returned.

No, just literal empty string -- though maybe I am making this up and it's not a valid tag value?

@aliu39 @billyvg i think my reasoning for removing the empty string suggestion is more like, having an empty tag value isn't a useful suggestion for users most of the time since they probably want to search on an actual name/version - i'd rather save cognitive load and just show suggestions that are actually values. maybe "" is a valid tag to search on but it's not necessarily useful to suggest

[aliu39]

Based on the results of the search I linked above, I don't think the search for "" is valid, so I'm good with removing it. My question is still why is this value returned by the backend - I can make a note for that or open a separate ticket.

We can also, maybe, support an explicit value that indicates "I want to search for replays missing this tag". Similar to what I did for user fields a while back. But if we don't have this functionality already, that's out of scope from this pr too.

[michellewzhang]

Based on the results of the search I linked above, I don't think the search for "" is valid, so I'm good with removing it. My question is still why is this value returned by the backend - I can make a note for that or open a separate ticket.

We can also, maybe, support an explicit value that indicates "I want to search for replays missing this tag". Similar to what I did for user fields a while back. But if we don't have this functionality already, that's out of scope from this pr too.

to me it just looks like these are the commonly searched values

[aliu39]

I worked on this endpoint for replays, these suggestions are from our database and count is the number of times a value appears in the table. Can follow up to look into this, but yeah for now, definitely seems like we shouldn't suggest these