It's possible for the `text` input to /v1/autocomplete to be of non-zero
length after trimming whitespace and quotes, but still be insufficient
to use for geocoding.
One common case is that it contains only commas, slashes, or other
delimiters.
Our query logic currently does not handle this case, and will generate
Elasticsearch queries that do not have a primary `must` clause and end
up searching every document in the index. These queries are slow, take
up cluster resources, and are not useful.
By detecting unsubstantial inputs, we can prevent this.
By definition, all boundary.country query matches will either be
identical, or not a match. Thus, it does not make sense to put the query
clause for boundary.country in the `must` section of the query.
In theory, because our queries would generally combine this `must`
clause with others, there shouldn't be any performance improvement (or
regression) from this change.
However, semantically, this clause fits better as a `filter`, and in the
case of a bug causing a degenerate query with the `boundary.country`
query clause as the only one under the `must` section, this would have a
big impact.
In the case where a min lat/lon is larger than a max lat/lon, the error
message was a bit confusing as it did not show the actual property name
or the values that are causing errors.
This condition will cause Elasticsearch to throw an error, we should
catch it outselves first.
The error is more friendly than the case where min>max, but still an
error.
Connects https://github.com/pelias/api/pull/1050
If bounding box lat/lon values are outside the correct range,
Elasticsearch throws very alarming errors.
With a little validation code we can provide more friendly and
actionable error messages.
Fixes https://github.com/pelias/pelias/issues/750
The NSP service is shutting down, and as far as I know we have not used
this tool frequently at all. NPM has better tools built in now, like
`npm audit`.
As I recall, this was only added to mitigate issues with running `npm
ls` and correctly showing all dependencies installed (see
https://github.com/pelias/api/issues/1179).
This change moves semantic-release out of dev-dependencies, but keeps
its functionality by calling semantic-release as usual in a `release`
TravisCI build stage. There are several advantages to this method:
1.) semantic-release is run only after all builds succeed. Our previous
approach could have theoretically run semantic-release when some Node.js
versions failed with the current code
2.) semantic-release (and it's many dependencies) are removed from
`node_modules`. This increases the speed of `npm install` in all cases,
and reduces the size of our Docker images by 20MB (from 284MB to 264MB)!
Since the only time semantic-release is needed is on TravisCI anyway, it
seems pointless that every installation of Pelias should include it.
3.) Because semantic-release is not in `package.json`, Greenkeeper will
not attempt to update it. Semantic release updates _very_ frequently,
and each update attempt seems to have a decent chance of experiencing a
random TravisCI failure, causing unwanted notifications.
There are probably downsides to this approach. For example, we should
consider pinning the major version of semantic release during install.
Additionally, and for obvious reasons, we can't fully test this change
until it's merged to the `production` branch. We should consider testing
it first on a lower priority repository.
If this change _does_ work well, we should consider adopting it
everywhere.
Peter Johnson
Julian Simioni
Julian Simioni
greenkeeper[bot]
Nuno Patronilo
Joxit