Bug overview description.
Entering alphabetic content on meta-tags that expect numeric input return zero valued results (e.g. score:foo is equivalent to entering score:0)
What part(s) of the site page(s) are affected?
Meta-tag Searching
What is the expected behavior?
Improper formatting of meta-tag searches should return zero results for any meta-tag search
What actual behavior is given instead?
Improperly formatting meta-tag searches can return results for meta-tags that expect numeric values
Time of incident (if applicable).
N/A
Can you reproduce the bug every time?
Yes!
What steps did you take to replicate this bug?
Execute the following searches to observe unexpected behavior in these meta-tags
-> score:foo
-> score:###
-> score:f72oo
-> favcount:hey
-> views:admins
-> comments:you
-> gentags:do
-> arttags:a
-> speciestags:fantastic
-> set:job

Errors or other messages returned (if any).
N/A

I'd say this is expected behaviour because the way that string.to_i works in ruby is:

#Yes this is python, because for me, it is quicker to write because I know it like the back of my hand.
def to_i(input):
    #Initialise the variable
    value = 0
    #For each character(EG: "ASDF" would be A, S, D, F)
    for character in input:
        #If the ascii value is between 48 and 57
        if 48 <= ord(character) <= 57:
            #Add 10 to shift the value left(EG: 45 becomes 450)
            value = value * 10
            #Remove the ascii value from the number
            #EG: "5" is 53, so 53 - 48 becomes 5
            #Also add it to value, so our new value looks like 455
            value = value + (ord(character) - 48)
        else:
            #Not a numeric character, return the string because probably hit the end of the string.
            return value

So "asdffdsa".to_i would return 0 because value is equal to 0 and was never set.
Removing all non-alphabetic characters from it, server side this is, would be a waste of CPU time.
My advice is to just not enter alphabetic characters in the meta tags. :v

I'm not sure any of the possible actions are user friendly. Of the three choices, using a safe default(or in this case the default conversion value) might be the best choice. Explicitly throwing a warning that indicates something else was expected might improve the experience, throwing an error and aborting the search seems like it would be unhelpful and frustrating, depending on how well explained the error message is.

Returning no results would be the least friendly way of handling this, as it is still a silent failure, but now you get no feedback on why your search returned absolutely nothing at all.

I'm not 100% sure, but I think the set tag can actually accept words, but only if the set exists and is public.

KiraNoot said:
I'm not sure any of the possible actions are user friendly. Of the three choices, using a safe default(or in this case the default conversion value) might be the best choice. Explicitly throwing a warning that indicates something else was expected might improve the experience, throwing an error and aborting the search seems like it would be unhelpful and frustrating, depending on how well explained the error message is.

Returning no results would be the least friendly way of handling this, as it is still a silent failure, but now you get no feedback on why your search returned absolutely nothing at all.

There should be a prominent warning or error message. And if there is, then it probably doesn't matter much what results are displayed, if any; the user is going to ignore them and fix their query anyway. But I would lean towards returning zero results to make it more obvious and to reduce load.

If it turns out to be too much work to add the warnings, then I think the only sane thing to do is to return zero results. The user needs to be told somehow that there's something wrong with their query.

The status quo of silently applying the default conversion rule is definitely the worst option. If it's too much work to fix, then so be it – but just from a user experience perspective, it defies all reasonable expectations. When a results page is presented to a user without error, the user should be able to trust its correctness.

I'm not 100% sure, but I think the set tag can actually accept words, but only if the set exists and is public.

Yep, eg. set:lancearmstrongfavs. I'm guessing the way this is internally implemented is :

• Try to convert to a number
• if result is 0, attempt to look up set # by name

Regarding what to do,
+1 on throwing a warning. Using a default for bad input (even if a warning is also shown) obfuscates the fact that the input was bad. If I was coding it, I would aim to make it return no results and an error, because I believe the user must be stopped in this case ;).

I will make an effort to revise the parser and have it throw warnings and no results when input defies expectations.

because I believe the user must be stopped

All I can think of are those high security bollards being hit by trucks.

KiraNoot said:
I'm not 100% sure, but I think the set tag can actually accept words, but only if the set exists and is public.

The "set:whatever" metatag uses the set's short name, which is always text. As far as I know, the set's ID is only used in the "set #whatever" Dtext.

Example: set #6082 is set:bleeding.

And a private set can be accessed by anyone who knows its ID or short name.

Example: set #8780 - set:getout2

savageorange said:
Yep, eg. set:lancearmstrongfavs.

you:holla

Hi Lance.
As you might have guessed, I like your set :)

KiraNoot said:
All I can think of are those high security bollards being hit by trucks.

Seems about right. People pay more attention after they crash headfirst into something, since they really don't like that.