Repository navigation
Conversation
…cheduler Keep the policy-expand row aligned when a maintenance policy with timeTrigger is created, altered, enabled, disabled, or deleted. Co-authored-by: Cursor <cursoragent@cursor.com>
lasdf1234
marked this pull request as draft
October 16, 2026 11:49
…uler transaction Write the policy-expand row in the same transaction as the policy change so a failed schedule rolls the policy write back. Co-authored-by: Cursor <cursoragent@cursor.com>
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
1 participant
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.
What changes were proposed in this pull request?
Follow-up on the TMS scheduler pools from Epic #13760.
When a maintenance policy carries
timeTrigger, create, alter, enable, disable, and delete keep a matchingpolicy-expandrow inscheduled_expand_tasks:timeTrigger, or a successful delete: remove the row.The expand handler is still a no-op. This change only registers the row. The db-scheduler client forces auto-commit, and the pools commit when auto-commit is off, so writes survive the entity-store connection pool.
Why are the changes needed?
Policy content stores
timeTrigger, but nothing was writing that schedule into db-scheduler. Without this, a created or updated maintenance policy never becomes an expand lease, and a deleted or disabled policy would leave a stale row.Fix: #13760
Does this PR introduce any user-facing change?
No new REST API or configuration key. Creating, altering, enabling, disabling, or deleting a maintenance policy that has
timeTriggernow inserts, moves, or deletes the correspondingpolicy-expandrow while TMS scheduler pools are running.How was this patch tested?
TestPolicyTimeTriggerEventListenercovers create, alter, enable, disable, delete, a failed delete, and non-maintenance policies.TestPolicyExpandSchedulerinserts, reschedules, and removes the expand row on the H2 entity-store schema../gradlew :plugins:tms:test --tests org.apache.gravitino.maintenance.scheduler.TestPolicyTimeTriggerEventListener --tests org.apache.gravitino.maintenance.scheduler.TestPolicyExpandScheduler --tests org.apache.gravitino.maintenance.scheduler.TestTableMaintenanceSchedulerPools -PskipITsMade with Cursor