[Enhancement] Record IVM source version/timestamp ranges in MV task run EXTRA_MESSAGE - #74605
Conversation
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ba72f7a3fa
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
198cffe to
d04e007
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d04e00752c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
d04e007 to
8108b75
Compare
|
@codex review |
|
Codex Review: Didn't find any major issues. More of your lovely PRs please. ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
rerun |
|
Re-run the workflow |
41c4090 to
87c8894
Compare
eb31393 to
8c261bb
Compare
…un EXTRA_MESSAGE
Record, for each IVM (incremental) MV refresh, the TVR version range
consumed from every base table and the matching Iceberg snapshot commit
times into information_schema.task_runs.EXTRA_MESSAGE:
- imvSourceVersionRange: {"catalog.db.tbl": {"start": "100", "end": "128"}}
- imvSourceTimestampRange: same shape, values are snapshot commit times
in epoch millis; endpoints that cannot be resolved (MIN/MAX sentinel
versions, expired/unknown snapshots, metadata errors) are omitted, so
a table degrades to {} instead of failing the refresh.
The ranges are recorded right after MVIVMRefreshProcessor stages the
per-table TVR deltas, through the existing best-effort
updateTaskRunStatus() path, so recording can never fail a refresh. PCT
runs leave both fields empty. Both setters cap entries via
MvUtils.shrinkToSize like the other EXTRA_MESSAGE maps.
These fields feed the IMV_SOURCE_* columns of the planned MV refresh
jobs system table.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Youngwb <yangwenbo_mailbox@163.com>
8c261bb to
9f8561d
Compare
[Java-Extensions Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
[FE Incremental Coverage Report]✅ pass : 47 / 49 (95.92%) file detail
|
[BE Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
…un EXTRA_MESSAGE (StarRocks#74605) Signed-off-by: Youngwb <yangwenbo_mailbox@163.com> Co-authored-by: Claude <noreply@anthropic.com> Signed-off-by: Oliver Layer <o.layer@celonis.com>
…un EXTRA_MESSAGE (StarRocks#74605) Signed-off-by: Youngwb <yangwenbo_mailbox@163.com> Co-authored-by: Claude <noreply@anthropic.com> (cherry picked from commit 95d2d9c) Signed-off-by: Youngwb <yangwenbo_mailbox@163.com>
…un EXTRA_MESSAGE (StarRocks#74605) Signed-off-by: Youngwb <yangwenbo_mailbox@163.com> Co-authored-by: Claude <noreply@anthropic.com> (cherry picked from commit 95d2d9c) Signed-off-by: Youngwb <yangwenbo_mailbox@163.com>
Why I'm doing:
An incremental (IVM) materialized view refresh consumes a specific snapshot range from each base table, but that range is currently only visible in FE logs. Exposing it on the task run makes every refresh auditable via
information_schema.task_runs.EXTRA_MESSAGE("which slice of the source did this refresh consume?"), and it is the data source for theIMV_SOURCE_*columns of the planned MV refresh-jobs system table.What I'm doing:
Record two new JSON sub-fields in the MV task run extra message for every IVM refresh, right after
MVIVMRefreshProcessorstages the per-table TVR deltas:imvSourceVersionRange:{"catalog.db.tbl": {"start": "100", "end": "128"}}— the TVR version (snapshot id) range consumed from each base table.TvrVersionMIN/MAX sentinels are rendered as"MIN"/"MAX"(readable, instead of leakingLong.MIN_VALUE/Long.MAX_VALUEliterals).imvSourceTimestampRange: same shape, values are the commit times of those versions in epoch millis. Resolution is delegated toTable.getVersionCommitTimeMillis(version)— a polymorphic seam whose base implementation returns empty and which each table format overrides (Iceberg resolves the snapshot's commit time); endpoints that cannot be resolved (sentinel versions, expired/unknown snapshots, formats with no version commit time) are omitted, so a table degrades to{}instead of failing the refresh. This keepsMVIVMRefreshProcessorformat-agnostic, so other IVM-capable table formats only need to override that one method.Recording goes through the existing best-effort
updateTaskRunStatus()helper (null-guarded, exception-swallowing), so it can never fail a refresh. Both setters cap map entries withMvUtils.shrinkToSize, mirroringpinnedSnapshotIdMap. PCT runs leave both fields as{}.Example after an incremental refresh:
Tests:
MVTaskRunExtraMessageTest(shrink-to-size + JSON serialization of the new fields),IVMBasedMvRefreshProcessorIcebergTest#testImvSourceVersionRangeRecordedOnExtraMessage(range values + degradation to{}for unresolvable snapshots, plus the empty base-Tableresolution),#testImvSourceTimestampRangeRecordedOnExtraMessage(commit times against real Iceberg snapshots on the mock catalog), and#testImvSourceRangesNotRecordedOnPctFallback(no stale ranges when hybrid falls back to PCT).test_ivm_task_run_source_range— PCT baseline run records nothing; incremental run records both ranges.Fixes #issue: N/A — observability enhancement, no tracking issue
What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist:
Bugfix cherry-pick branch check: