Search: preserve operation id (e.g. _bulk) in OpenAPI search_title#3614
Merged
Conversation
reakaleek
approved these changes
Jul 6, 2026
OpenAPI docs are built in two stages, and the second silently overwrote the first's search_title: OpenApiDocumentExporter set Title == SearchTitle, but ElasticsearchMarkdownExporter's CommonEnrichments then unconditionally rebuilt SearchTitle via CreateSearchTitle(), which derives extra tokens from the URL by splitting on '/', ' ', '-', '.', and '_'. For the Bulk API (operation id "_bulk", URL segment "operation-_bulk"), that split turned "_bulk" into a bare "bulk" token, which then got deduplicated against the title's existing "Bulk" token and dropped entirely — the literal, highly-searched "_bulk" endpoint name never made it into search_title. Fix: let OpenAPI docs own their SearchTitle. CommonEnrichments now only rebuilds it for non-API content (doc.ContentType != "api"); OpenApiDocumentExporter builds a dedicated search title that appends the raw operation id verbatim (underscore/casing intact). Also drops a stray trailing space in Title that caused a visible double space in the reported string. Checked website-search-data's search_title mapping/analysis: no change needed there. search_title is analyzed by synonyms_fixed_analyzer/synonyms_analyzer, both using group_tokenizer, whose delimiter set doesn't include '_' or '.', so _bulk (and dotted ids like ml.start_datafeed) index and search as a single token. Flagged separately (not blocking, not part of this fix): title.starts_with's EdgeNGram tokenizer token_chars omits "punctuation" and would strip a leading underscore if operation ids are ever also added to Title. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
114eab9 to
93a2f13
Compare
…tle-operation-id # Conflicts: # src/Elastic.Markdown/Exporters/Elasticsearch/ElasticsearchMarkdownExporter.Export.cs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
For OpenAPI-exported docs (e.g. the Elasticsearch Bulk API, operation id
_bulk),search_titlecurrently reads"Bulk index or delete documents - Elasticsearch API - doc operation"— the operation id never appears, and its leading underscore would be lost even if it did. Users search Elasticsearch docs by REST endpoint name a lot (_bulk,_search,_cat, dotted ids likeml.start_datafeed), so this is a real, missing search token.Root cause: OpenAPI docs are built in two stages, and the second silently overwrites the first's
search_title.OpenApiDocumentExportersetsTitle == SearchTitle, butElasticsearchMarkdownExporter.CommonEnrichmentsthen unconditionally rebuildsSearchTitleviaCreateSearchTitle(), which derives extra tokens from the URL by splitting on/,,-,., and_. For the Bulk API (URL segmentoperation-_bulk), that split turns_bulkinto a barebulk, which then gets deduplicated against the title's existingBulktoken and dropped entirely.Fix: let OpenAPI docs own their
SearchTitle.CommonEnrichmentsnow only rebuildsSearchTitleviaCreateSearchTitle()for non-API content (doc.ContentType != "api") — markdown docs are unaffected.OpenApiDocumentExporterbuilds a dedicated search title appending the raw operation id verbatim (underscore/casing intact):"Bulk index or delete documents - Elasticsearch API - _bulk". Also drops a stray trailing space inTitlethat caused the reported double space.website-search-data check: no mapping/analyzer change needed.
search_titleis analyzed bysynonyms_fixed_analyzer/synonyms_analyzer, both usinggroup_tokenizer, whose delimiter set doesn't include_or.— so_bulk(and dotted ids likeml.start_datafeed) index and search as a single token, both index- and search-time, including on thecompletion(search_as_you_type) sub-field. Flagged separately, not blocking:title.starts_with's EdgeNGram tokenizertoken_charsomits"punctuation"and would strip a leading underscore if operation ids are ever added toTitletoo.Test plan
dotnet buildforElastic.MarkdownandElastic.ApiExplorersucceedsOpenApiSearchTitleTests(Elastic.Markdown.Tests) — assertsCommonEnrichmentspreserves the API exporter'ssearch_titleand still rebuilds it for markdown docsOpenApiOperationIdSearchTitleTests(Elastic.ApiExplorer.Tests) — exercisesOpenApiDocumentExporter.ConvertToDocumentsagainst an in-memory Bulk API spec (no network), assertssearch_title=="Bulk index or delete documents - Elasticsearch API - _bulk"Elastic.Markdown.TestsandElastic.ApiExplorer.Testssuites run; pre-existing failures are unrelatedScopedFileSystem/git-checkout tests failing in this worktree environmentdotnet format/ lint clean (pre-push hook passed)