HomePhabricator

Limit the damage that degenerate project name typeahead queries can cause

Tags
None
Referenced Files
None
Subscribers
Tokens
"Like" token, awarded by 20after4.

Description

Limit the damage that degenerate project name typeahead queries can cause

Summary:
See PHI47. When users copy/paste a wall of text into a project tokenizer, we can end up performing a very large number of JOINs.

These JOINs seem okay locally and on secure, but the install in PHI47 reports hitting issues.

Since these queries are almost certainly illegitimate (I think no one uses 5+ words to find a project), just limit the search to the 5 longest tokens.

Note that typing 6 tokens will still almost always work, since the UI does additional filtering. However, if you have 100+ projects named "a b c d e ..." and search for "a b c d e z", you may not hit it. This is so degenerate that it's hard to imagine any users encountering it.

This is a stopgap fix, I'll file something longer-term as a followup.

Test Plan: Used /typeahead/class/PhabricatorProjectDatasource/ to run queries. Saw the same results with shorter query plans for all reasonable queries.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D18506

Details

Provenance
epriestleyAuthored on Aug 30 2017, 6:08 PM
epriestleyPushed on Aug 30 2017, 6:23 PM
Reviewer
chad
Differential Revision
D18506: Limit the damage that degenerate project name typeahead queries can cause
Parents
rP11046d495dbf: Add a selected button ui state
Branches
Unknown
Tags
Unknown
Build Status
Buildable 18226
Build 24513: Run Core Tests

Event Timeline

FWIW we ran into this problem at wikimedia. In fact, I think it was the thing that killed innodb enough times to motivate us to move to elasticsearch. Elastic handles whatever you throw at it.

This query is always always driven by MySQL whether ElasticSearch is configured or not (and never served by any FULLTEXT engine), so I would not expect moving to ElasticSearch to have any effect here.

This query is always always driven by MySQL whether ElasticSearch is configured or not (and never served by any FULLTEXT engine), so I would not expect moving to ElasticSearch to have any effect here.

Sorry I got it mixed up with a different query - the one we had problems with was the query in the "edit related tasks" dialog.

Ah, that makes sense. Yeah, that one is driven by the whole FULLTEXT chain.