jerryshao opened a new pull request, #11978: URL: https://github.com/apache/gravitino/pull/11978
### What changes were proposed in this pull request? `BuiltInJobTemplateEventListener.reconcileBuiltInJobTemplates()` decided whether to refresh a persisted built-in job template by comparing only the `version` custom field. This PR makes it also compare the full template content (via `JobTemplate.equals()`) and refresh the persisted record whenever it drifts, regardless of the version field. Also added a regression test, `testReconcileBuiltInJobTemplatesUpdateWhenExecutableChangedButVersionSame`. ### Why are the changes needed? The `executable` path of a built-in job template is resolved from the on-disk jar location at server startup (`BuiltInJob.resolveExecutable()`), so it changes across a Gravitino release upgrade even though the job logic version (`"v1"`) stays the same. Since reconciliation only checked `version`, the stale jar path from the old release was never refreshed in the database, causing built-in job runs to fail after upgrade with `Source file does not exist: /opt/gravitino/auxlib/gravitino-jobs-<old-version>.jar`. Fix: #11976 ### Does this PR introduce _any_ user-facing change? No user-facing API changes. Built-in job templates will now self-heal their `executable` path (and other fields) on server startup after an upgrade, instead of requiring manual intervention. ### How was this patch tested? Added a unit test verifying that when `executable` differs but `version` is unchanged, the persisted template is updated. Ran `TestBuiltInJobTemplateEventListener` (14 tests, all passing). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
