-
Bug
-
Resolution: Not a Bug
-
Undefined
-
None
-
None
-
None
-
False
-
-
False
-
-
Edit:
We will need to add the ElasticSearch plugin. This may require adding a new service.
When components and APIs are created it is not included in the search results right away. With a special case of the initial DB being empty, after first components and APIs are created it's not indexed right away neither and the following error is returned in API call to the search endpoint:
{
"error": {
"name": "MissingIndexError",
"message": "Missing index for software-catalog. This could be because the index hasn't been created yet or there was a problem during index creation."
},
"request": {
"method": "GET",
"url": "/query?term=&types%5B0%5D=software-catalog"
},
"response": {
"statusCode": 500
}
}
While the following error is thrown in the RHDH backend log:
2023-12-08T14:08:00.789Z backstage error Request failed with status 500 Missing index for software-catalog. This could be because the index hasn't been created yet or there was a problem during index creation. type=errorHandler cause=undefined name=MissingIndexError stack=MissingIndexError: Missing index for software-catalog. This could be because the index hasn't been created yet or there was a problem during index creation. at LunrSearchEngine.query (/opt/app-root/src/node_modules/@backstage/plugin-search-backend-node/dist/index.cjs.js:371:13) at /opt/app-root/src/node_modules/@backstage/plugin-search-backend/dist/cjs/router-eea67d06.cjs.js:445:65 at handleReturn (/opt/app-root/src/node_modules/express-promise-router/lib/express-promise-router.js:24:23) at /opt/app-root/src/node_modules/express-promise-router/lib/express-promise-router.js:64:7 at handleReturn (/opt/app-root/src/node_modules/express-promise-router/lib/express-promise-router.js:24:23) at /opt/app-root/src/node_modules/express-promise-router/lib/express-promise-router.js:64:7 at Layer.handle [as handle_request] (/opt/app-root/src/node_modules/express/lib/router/layer.js:95:5) at next (/opt/app-root/src/node_modules/express/lib/router/route.js:144:13) at Route.dispatch (/opt/app-root/src/node_modules/express/lib/router/route.js:114:3) at Layer.handle [as handle_request] (/opt/app-root/src/node_modules/express/lib/router/layer.js:95:5) at /opt/app-root/src/node_modules/express/lib/router/index.js:284:15 at Function.process_params (/opt/app-root/src/node_modules/express/lib/router/index.js:346:12) at next (/opt/app-root/src/node_modules/express/lib/router/index.js:280:10) at Layer.handle [as handle_request] (/opt/app-root/src/node_modules/express/lib/router/layer.js:91:12) at trim_prefix (/opt/app-root/src/node_modules/express/lib/router/index.js:328:13) at /opt/app-root/src/node_modules/express/lib/router/index.js:286:9
It takes several minutes before the new entities are indexed and appear in search results.
NOTE: According to the official Backstage docs the recommended search engine is Elastic search, citation:
When the Backstage Search Platform was first released, it came with an in-memory search engine as default - Lunr. While this is a good engine to use on a smaller scale and for local development (to avoid having to set up a search engine instance separately), it also has its limitations such as:
- Lunr does not scale well. Horizontally scaled deployments of Backstage and/or Backstage Search backend using Lunr result in either duplicated indexing processes and indices or inconsistent index state across nodes.
- Lunr’s filter functionality is limited, especially for logical AND/OR operators.
- Lunr has a smaller community than Elasticsearch, which could mean that adopters relying on it will have less by way of resources for iterating on and improving search.
Therefore, we recommend using Elasticsearch for production usage. Moving forward, the search maintainers will prioritize the Elasticsearch engine while we’ll rely on the community to maintain the Postgres engine.
