Repository navigation
Give ingest processors their own page and link type pages by schema id - #4376
Conversation
A row like `knn.filter` reads "One of: QueryContainer[] or QueryContainer". The `QueryContainer` option was styled as a link but was plain text, and `QueryContainer[]` was not even styled. Both now link to the `QueryContainer` page in the same tab, as the type of a row already does. The `[]` stays outside the link, so the link names the type. The Markdown export links them too. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The ingest pipeline pages were almost all processor listings: 519 of `ingest-put-pipeline`'s 519 rows, repeated on `ingest-simulate` and `simulate-ingest`. `ProcessorContainer` now gets a page under Types, Ingest, as QueryContainer and the aggregations do, and those rows link to it. `ingest-put-pipeline` drops to 12 rows. Which types get a page lived in three hardcoded places, keyed by display name, so any schema whose short name was `Aggregate` linked to the Elasticsearch page. `TypePages` now lists each page once with its schema id, navigation category and map spelling, and rows link by `$ref` id. The name-based link styling goes too: it styled `QueryContainer` as a link on its own page and wherever it was not one. A type line built by `Describe`, such as a response type, now carries a real link instead. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
![infra-vault-gh-plugin-prod[bot]](https://avatars.githubusercontent.com/u/6764390?s=60&v=4){kind=small}
| ("AggregationContainer", "Aggregations"), | ||
| ("Aggregate", "Aggregations"), | ||
| ("ProcessorContainer", "Ingest") | ||
| ); |
There was a problem hiding this comment.
Severity: P3 (Low)
The new ProcessorContainer page and pipeline link lack an end-to-end regression test, so a wiring failure could leave processor definitions unreachable while the registry tests still pass.
Generated by Libra. React with 👍 or 👎 to give feedback on this comment.
There was a problem hiding this comment.
Added in the latest commit on this branch: TypePageWiringTests.ProcessorContainer_GetsAnIngestPageThatPipelineRowsLinkTo. It builds a small ingest spec through OpenApiGenerator, finds the ProcessorContainer page under the Ingest category, and checks that the pipeline's processors row links to the exact URL that page is served at and lists nothing inline. It also checks that the page's own on_failure row does not link back to itself. With a wrong schema id in TypePages, the test fails because navigation creates no page.
There was a problem hiding this comment.
Thanks for adding this. I confirmed ProcessorContainer_GetsAnIngestPageThatPipelineRowsLinkTo is present and exercises the end-to-end wiring you describe: the page appears under Ingest, the pipeline row links to its served URL without inline children, and the page does not link to itself. This addresses my finding about the missing regression test. See the test.
Generated by Libra. React with 👍 or 👎 to give feedback on this comment.
The registry tests would still pass if navigation stopped creating the `ProcessorContainer` page, or if a pipeline row linked to a URL other than the one the page is served at. The new test builds a small ingest spec through `OpenApiGenerator`, finds the page under Ingest, and checks that the pipeline's `processors` row links to that page's URL and lists nothing inline. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Docs preview (local build)Handbook preview: https://docs-v3-preview.elastic.dev/elastic/docs-builder/pull/4376/ Sample changed pages: |
1 participant
Ingest processors get an API Explorer type page of their own, next to Query DSL and Aggregations. The pipeline pages link to it instead of listing every processor, so
ingest-put-pipelinedrops from 519 rows to 12. Type pages are now matched by schema id, and option names such asQueryContainer[]link to their page.Stack: 1 of 2. #4371, the variant chips, builds on this PR and targets it until it is merged.
Affects:
API reference,DocumentationPrompt summary: The author asked which other types warrant a page of their own, then asked for a refactor that lists type pages in one place by schema id, plus a page for ingest processors. These changes started on #4371 and moved to this PR so that #4371 keeps only the variant chips.
Why
The pipeline pages repeated the full list of ingest processors: 509 of
ingest-put-pipeline's 519 rows, and again oningest-simulateandsimulate-ingest. Which types had a page was decided by display name in three hardcoded places, so any schema whose short name wasAggregatewould link to the Elasticsearch page. A row such asknn.filterstyled itsQueryContaineroption as a link, but it was plain text.What
A page for ingest processors
ingest._types.ProcessorContainergets a page under Types › Ingest that lists all 46 processors. Rows of that type link there, as rows ofQueryContaineralready do.ingest-put-pipelineingest-simulatesimulate-ingestType pages listed once, matched by schema id
TypePageslists each type page once, with its schema id, navigation category and map spelling. Navigation builds the pages from it, and rows link by$refid rather than by display name, so a schema that only shares a short name lists its own fields. Adding a type page is now one entry in that list.Links where the row only looked linked
Options in a row such as "One of: QueryContainer[] or QueryContainer" now link to their page, with the
[]outside the link; there are 306 such options on 18 pages. A type line built byDescribe, such as a response type, links too. Name-based link styling is gone: it styledQueryContaineras a link on its own page and wherever it was not one.Where to look
processors, linking to the new pageProcessorContainerpageknn.filter, options linking toQueryContainerVerify
A comparison of 1,322 Elasticsearch and Kibana pages against
mainfinds three changes: the new navigation entry on every Elasticsearch page, the linked options, and the shorter ingest pages.🤖 Generated with Claude Code