Skip to content

Add an overridable table-config-change callback distinct from index-loading-config fetch#18792

Merged
KKcorps merged 1 commit into
apache:masterfrom
krishan1390:decouple-config-change-callback
Jun 18, 2026
Merged

Add an overridable table-config-change callback distinct from index-loading-config fetch#18792
KKcorps merged 1 commit into
apache:masterfrom
krishan1390:decouple-config-change-callback

Conversation

@krishan1390

Copy link
Copy Markdown
Contributor

The server's table-config/schema refresh message handler called fetchIndexLoadingConfig() purely for its cache-refresh side effect, discarding the returned config. That same fetchIndexLoadingConfig() is also invoked incidentally during segment state transitions and reloads, so a table data manager had no way to distinguish "the config actually changed" from "an index loading config was fetched while a transition was in progress."

This adds a dedicated onTableConfigOrSchemaRefresh() callback on TableDataManager. The default implementation refreshes the cached table config and schema (preserving today's behavior), and the refresh message handler now invokes the callback instead of fetchIndexLoadingConfig(). The behavior of fetchIndexLoadingConfig() during transitions is unchanged. This gives implementations a hook that fires only on a genuine config/schema change.

Testing

BaseTableDataManagerTest#testOnTableConfigOrSchemaRefreshRefreshesCachedConfig verifies the default callback refreshes the cached config/schema. Existing data-manager and server tests pass.

🤖 Generated with Claude Code

…oading-config fetch

The server's table-config/schema refresh message handler previously called
fetchIndexLoadingConfig() purely for its cache-refresh side effect, discarding the
returned config. That same fetchIndexLoadingConfig() is also invoked incidentally during
segment state transitions and reloads, so there was no way for a table data manager to
distinguish "the config actually changed" from "an index loading config was fetched while
a transition was in progress".

Introduce a dedicated onTableConfigOrSchemaRefresh() callback on TableDataManager (default
implementation refreshes the cached table config and schema, preserving today's behavior)
and invoke it from the refresh message handler instead of fetchIndexLoadingConfig(). This
gives table data managers a hook that fires only on a genuine config/schema change, while
leaving the behavior of fetchIndexLoadingConfig() during transitions unchanged.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

@krishan1390 krishan1390 left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No blocking issues found in review.

@krishan1390

Copy link
Copy Markdown
Contributor Author

Minor (non-blocking): the concrete @Override onTableConfigOrSchemaRefresh() in BaseTableDataManager has the same body as the interface default (fetchIndexLoadingConfig()), so it is technically redundant. Keeping it is defensible as a discoverable extension seam alongside the other @Overrides, but you could drop it and rely solely on the default if you prefer less duplication. Either is fine. Javadoc, wiring, back-compat, and the test all look good.

@codecov-commenter

codecov-commenter commented Jun 17, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 40.00000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.80%. Comparing base (b6b3b6c) to head (9f99abf).
⚠️ Report is 1 commits behind head on master.

Files with missing lines Patch % Lines
...t/segment/local/data/manager/TableDataManager.java 0.00% 2 Missing ⚠️
...er/starter/helix/SegmentMessageHandlerFactory.java 0.00% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##             master   #18792      +/-   ##
============================================
+ Coverage     64.78%   64.80%   +0.01%     
  Complexity     1309     1309              
============================================
  Files          3380     3380              
  Lines        209630   209634       +4     
  Branches      32822    32822              
============================================
+ Hits         135817   135843      +26     
+ Misses        62883    62860      -23     
- Partials      10930    10931       +1     
Flag Coverage Δ
custom-integration1 100.00% <ø> (ø)
integration 100.00% <ø> (ø)
integration1 100.00% <ø> (ø)
integration2 0.00% <ø> (ø)
java-21 64.80% <40.00%> (+0.01%) ⬆️
temurin 64.80% <40.00%> (+0.01%) ⬆️
unittests 64.79% <40.00%> (+0.01%) ⬆️
unittests1 56.98% <50.00%> (+0.01%) ⬆️
unittests2 37.27% <0.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@krishan1390 krishan1390 marked this pull request as ready for review June 18, 2026 05:56
@KKcorps KKcorps merged commit 4e6445c into apache:master Jun 18, 2026
11 checks passed
cypherean pushed a commit to cypherean/pinot that referenced this pull request Jun 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants