I'll make sure to update this task with full reproduction steps on Monday.

As for the commit, I'm not sure why that isn't in the upstream. I run off
stable and don't run any custom code. I do sometimes have to do a merge
commit when i pull down changes so maybe i did something weird when we
switched from running off master to running off stable.

When I ran into this issue, I was attempting to automatically file tasks when my application encountered some unknown exception/error. I didn't want to file duplicate tasks for the same errors, so I was first going to look up the task name that followed some standard format like Error: <file> <line> .... I was testing with the string This is a test and was confused whythe conduit maniphest.search endpoint was not returning any results, but I could lookup other task names fine.

This could just be T9979 but since it appears to work if you stem the corpus and pass that into the search, it looked like a bug to me and I thought I'd report it.

I can get around this by just hashing some unique string that makes up the error and dumping that into the task description and search off of that since full-text searching for single strings works as expected.

I can get around this by just hashing some unique string that makes up the error and dumping that into the task description and search off of that since full-text searching for single strings works as expected.

You should probably do this anyway, since stemming means that "deleting notes" might find a "delete note" task and incorrectly merge into it.

If the unique string you hash is generated by mushing together all the paths and line numbers of the stack trace, your hash will also be robust to parameterized error messages. When I've done this in the past, using this strategy was effective in merging error messages like "The name you entered, "<variable user text>", is not valid. It must have exactly three uppercase letters.", which won't merge cleanly if you just use the error message because each message will have different user text.

Also, searching for "this is a test" (with quotes) looks like it works correctly. Maybe you're searching for this is a test to get around the variant-text issue?

I don't think this is a stemming problem. Note that we MATCH(corpus, stemmedCorpus) against the query, so we're actually searching in the text "this is a test thi test". I wrote stemming so that it should never match fewer documents than an unstemmed query would -- definitely possible I got something wrong, but that's the intent, at least: stemming only gives you more hits.

Rather, MySQL seems to treat an "AND" term in "IN BOOLEAN MODE" which is below the minimum token length as never valid in InnoDB. Here's a simplified case:

These behaviors feel fairly unintuitive and possibly buggy to me, but we can work around them relatively easily.

This appears to also affect words on the stopword list, even if they are longer than the minimum token length. This is a pain because we can't read the stopword list directly from MySQL in MyISAM, but still something we can navigate.

According to that test, your server does not support InnoDB fulltext, so what you're seeing is expected: we keep the tables with FULLTEXT indexes on MyISAM if innodb_ft_max_token_size is not a defined system variable.

If you keep following the chain back with git show, you should figure out what started the divergence, which is likely a local commit.

You can also probably identify it something like this:

$ git log stable --not origin/stable

You can git reset --hard origin/stable to discard all your local commits and merges, which should stop producing merge commits when you git pull. However, you should figure out where the divergence started first, in case it was something important that you don't remember.

(There's some tiny possibility that upstream force-push hyjinx were involved -- we've force-pushed a handful of times to remedy various errors which were caught quickly enough -- but that commit doesn't look very suspicious from a force-push perspective.)

I probably did something dumb when changing over from master to stable (I'm the only one that administers this instance and I know we've never modified phab's source). I should be good to go on the version front now?

Also, I tried to buy you and Chad some beers but I'm seeing the following error when I try to add a payment method via Phortune (I know it's a prototype, so feel free to just ignore).

There was an error decoding error information submitted by the client. Expected a JSON-encoded list of error codes, received: nothing.

epriestley renamed this task from Stemming + MySQL Fulltext search can lead to unexpected results to MySQL fulltext search returns no results in boolean mode when a query includes +"x", where "x" is a stopword or short token.Apr 13 2017, 12:05 AM