4adf4b3dd7
renamed some queries to be quite a bit more informative, however it
wasn't obvious that these query names were used elsewhere in the code.
With those changes, no confidence score middleware was running, which
this should help fix.
In cases where several conditions are met, it is possible for results to
be returned from the API that are not sorted as they were intended.
These conditions are:
* over 10 results total were returned from Elasticsearch
* the interpolation middleware was called
* not all street results end up with possible interpolated address
matches, and some of those streets come before other interpolated
address records, necessitating a re-sorting of the results in the
interpolation middleware
In these cases, the ordering of streets as defined by Elasticsearch,
such as by linguistic match or distance from a focus point, will no
longer be respected in the results.
This is because Node.js's `Array.prototype.sort` uses an
[*un*stable QuickSort for arrays of size 11 or greater](https://github.com/nodejs/node/blob/master/deps/v8/src/js/array.js#L670).
The solution is to switch to a sorting algorithm that is always stable.
This ensures that whatever ordering was specified in the Elasticsearch
queries is observed, without any of that logic having to be duplicated,
and then possibly conflict.
Stable sorting is provided by the [stable](http://npmjs.com/stable) NPM
package.
This url is used to show attribution information for Pelias data sources
It was often not detected correctly if, for example, the API is proxied
behind a load balancer.
In some error cases, a warning is repeated many many times. It turns out
there is code checking against elasticsearch error codes, and warning
_each_ time it fails to match aganst one of them.
Many times, the error that is being compared is not from elasticsearch,
and in any case, the [elasticsearch-exceptions](https://www.npmjs.com/package/elasticsearch-exceptions)
module is 3 years old. We should rewrite most of this code and stop
using that module.
For now, this at least reduces log noise.
This header is only relevant if dealing with authentication via cookies
or other methods in HTTP requests. The Pelias API intentionally doesn't
deal with authentication at all, assuming anyone who wants
authentication will deal with it using a service placed between Pelias
and end users.
Additionally the CORS spec [does not allow](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Credentialed_requests_and_wildcards)
specifying this header while setting a wildcard for
`Access-Control-Allow-Origin`, so it can cause problems in some cases.
Fixes https://github.com/pelias/api/issues/971
Fallback and interpolation queries rely on several results coming back
from Elasticsearch to ensure the best result is returned. It was
possible that queries with `size=1` would not return enough results from
Elasticsearch. This change ensures even with `size=1` a sufficient
number of results are returned.
Fixes https://github.com/pelias/pelias/issues/562