User story
As a terminology maintainer, I want concept search projections to stay accurate after I change a source's locale configuration, so that GraphQL and other index-backed consumers do not serve outdated display names.
Use case
A curator changes a source's default_locale or supported_locales. Existing concepts under that source keep serving their previously indexed display_name in GraphQL, even though the ORM now resolves a different preferred name for the same concept.
Requirements
Acceptance criteria
More details (collapsible)
Context and origin
Found during code review (chatgpt-codex-connector bot) on the GraphQL permission-aware source and concept projections PR, on core/graphql/indexed.py.
Original finding: "When a source's default_locale or supported_locales changes, these projections continue serving the previously indexed display_name and preferred_description, even though both values are derived from the parent source's locale configuration. Source persistence only reindexes concepts for release or match-algorithm changes, and the new signal propagation handles only activity and visibility, so a lean query requesting display or description remains stale indefinitely while the ORM path returns the new locale selection."
Note: the original finding also mentioned preferred_description. That field was removed from the index in a later revision of the same PR (concept descriptions are locale-resolved per concept and are now served through the database fallback instead of being indexed), so this issue covers display_name only.
Confirmed in code:
Concept.display_name (core/concepts/models.py) resolves via preferred_locale, which reads self.parent.default_locale and self.parent.supported_locales.persist_changes (core/common/models.py) only sets should_reindex_resources on released change and should_reindex_concepts_only on has_semantic_match_algorithm change. Locale fields are not checked.core/sources/signals.py propagate_parent_attributes only propagates is_active and public_access to concepts, not locale configuration.
Severity: Warning (non-blocking). Stale display names are a data-freshness issue, not a security or correctness-of-access issue, and only affect the index-only GraphQL projection path. The ORM-hydrated path already resolves the correct value on every request.
Suggested priority: P2, matching the original review comment.
User story
As a terminology maintainer, I want concept search projections to stay accurate after I change a source's locale configuration, so that GraphQL and other index-backed consumers do not serve outdated display names.
Use case
A curator changes a source's
default_localeorsupported_locales. Existing concepts under that source keep serving their previously indexeddisplay_namein GraphQL, even though the ORM now resolves a different preferred name for the same concept.Requirements
default_locale.supported_locales.persist_changes(core/common/models.py), which currently reindexes concepts only onreleasedorhas_semantic_match_algorithmchanges.core/sources/signals.py, which currently only propagatesis_activeandpublic_accessto concepts.Acceptance criteria
default_localechanges, then those concepts are reindexed and their indexeddisplay_namereflects the new locale resolution.supported_localeschanges, then those concepts are reindexed and their indexeddisplay_namereflects the new locale resolution.More details (collapsible)
Context and origin
Found during code review (chatgpt-codex-connector bot) on the GraphQL permission-aware source and concept projections PR, on
core/graphql/indexed.py.Original finding: "When a source's default_locale or supported_locales changes, these projections continue serving the previously indexed display_name and preferred_description, even though both values are derived from the parent source's locale configuration. Source persistence only reindexes concepts for release or match-algorithm changes, and the new signal propagation handles only activity and visibility, so a lean query requesting display or description remains stale indefinitely while the ORM path returns the new locale selection."
Note: the original finding also mentioned
preferred_description. That field was removed from the index in a later revision of the same PR (concept descriptions are locale-resolved per concept and are now served through the database fallback instead of being indexed), so this issue coversdisplay_nameonly.Confirmed in code:
Concept.display_name(core/concepts/models.py) resolves viapreferred_locale, which readsself.parent.default_localeandself.parent.supported_locales.persist_changes(core/common/models.py) only setsshould_reindex_resourcesonreleasedchange andshould_reindex_concepts_onlyonhas_semantic_match_algorithmchange. Locale fields are not checked.core/sources/signals.pypropagate_parent_attributesonly propagatesis_activeandpublic_accessto concepts, not locale configuration.Severity: Warning (non-blocking). Stale display names are a data-freshness issue, not a security or correctness-of-access issue, and only affect the index-only GraphQL projection path. The ORM-hydrated path already resolves the correct value on every request.
Suggested priority: P2, matching the original review comment.