A helpful but sometimes confusing part of the APIs behavior is that it queries Elasticsearch on startup to get the list of custom sources and layers.
We had a report from a Pelias user with custom layers that they were no longer seeing them after running pelias compose down && pelias compose up. It turned out that telling both the API and Elasticsearch to start up at the same time doesn't work. The API's initial query to Elasticsearch will fail, so it won't detect any custom sources and layers.
While we have the pelias elastic wait command to help with this, the "safe" way to stop and start all Pelias components is rather verbose: pelias compose kill && pelias elastic start && pelias elastic wait && pelias compose up.
What if instead we added a couple retries to the API's Elasticsearch request? Elasticsearch usually starts up within a few seconds, and then the call to detect custom sources and layers would work fine.
A helpful but sometimes confusing part of the APIs behavior is that it queries Elasticsearch on startup to get the list of custom sources and layers.
We had a report from a Pelias user with custom layers that they were no longer seeing them after running
pelias compose down && pelias compose up. It turned out that telling both the API and Elasticsearch to start up at the same time doesn't work. The API's initial query to Elasticsearch will fail, so it won't detect any custom sources and layers.While we have the
pelias elastic waitcommand to help with this, the "safe" way to stop and start all Pelias components is rather verbose:pelias compose kill && pelias elastic start && pelias elastic wait && pelias compose up.What if instead we added a couple retries to the API's Elasticsearch request? Elasticsearch usually starts up within a few seconds, and then the call to detect custom sources and layers would work fine.