Render Helm customIndexes at the config path Ditto actually reads - #2540
Merged
thjaeckle merged 1 commit intoSep 3, 2026
Merged
Conversation
`thingsSearch.config.customIndexes` never reached Ditto. The template emitted the
block under
ditto.search.updater.persistence.custom-indexes
while SearchConfigValue declares
CUSTOM_INDEXES("index-initialization.custom-indexes", Collections.emptyMap())
so DittoSearchConfig#loadCustomIndexes looks under
`ditto.search.index-initialization.custom-indexes` and finds nothing. search.conf
documents the same location - `custom-indexes {}` sits inside the
`index-initialization { }` block, next to `activated-index-names`.
The consequence is worse than the feature silently doing nothing. Because
IndexInitializer.dropUndefinedIndices() removes every index whose name is neither
built-in nor a *configured* custom index, declaring an index in the chart made Ditto
drop it on startup rather than create and keep it. Operators who had pre-created the
index by hand - the recommended approach on a large collection, where a rolling build
avoids a cold create - lost it on the next things-search restart.
Observed on a cluster after deploying a chart that declared two custom indexes:
index-initialization is aware of defined indices:
[_namespace, global_read, v_wildcard, v_wildcard_id]
Dropping undefined indices: [ns_currently_mounted, ns_type_usagetype]
Index-Initialization was successful.
The fix is positional only: move the block inside `index-initialization`. The emitted
HOCON shape ("name" { fields = [ { name, direction } ] }) already matched search.conf
and is unchanged.
Verified by rendering the chart with a customIndexes value: the block is now nested in
index-initialization, no stray `updater { }` block remains, and a render without
customIndexes emits no custom-indexes at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Thomas Jäckle <thomas.jaeckle@beyonnex.io>
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
2 participants
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.
thingsSearch.config.customIndexesnever reached Ditto. The template emitted the block underwhile SearchConfigValue declares
so DittoSearchConfig#loadCustomIndexes looks under
ditto.search.index-initialization.custom-indexesand finds nothing. search.conf documents the same location -custom-indexes {}sits inside theindex-initialization { }block, next toactivated-index-names.The consequence is worse than the feature silently doing nothing. Because IndexInitializer.dropUndefinedIndices() removes every index whose name is neither built-in nor a configured custom index, declaring an index in the chart made Ditto drop it on startup rather than create and keep it. Operators who had pre-created the index by hand - the recommended approach on a large collection, where a rolling build avoids a cold create - lost it on the next things-search restart.