fix(workflows): skip PipelineServiceClient initialization during migrate#27522
Merged
fix(workflows): skip PipelineServiceClient initialization during migrate#27522
Conversation
yan-3005
added
the
safe to test
yan-3005
added
the
safe to test
Code Review ✅ ApprovedWorkflow pipeline service client initialization is now skipped during migration to prevent unnecessary resource allocation. No issues found. OptionsDisplay: compact → Showing less information. Comment with these commands to change:
Was this helpful? React with 👍 / 👎 | Gitar |
Contributor
There was a problem hiding this comment.
Pull request overview
Prevents migrate executions from failing due to missing runtime-only workflow dependencies by skipping PipelineServiceClient/expression-map initialization in migration context.
Changes:
- Guard
WorkflowHandlerexpression-map initialization so it only runs in runtime mode (not during migration). - Add a regression test ensuring migration mode does not attempt to construct a
PipelineServiceClient(and therefore won’t fail if the configured class isn’t on the migrate classpath).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
openmetadata-service/src/main/java/org/openmetadata/service/governance/workflows/WorkflowHandler.java |
Skips initializeExpressionMap when isMigrationContext is true to avoid loading runtime-only pipeline client classes during migrations. |
openmetadata-service/src/test/java/org/openmetadata/service/governance/workflows/WorkflowHandlerSchemaUpdateTest.java |
Adds coverage to ensure migration initialization does not call PipelineServiceClientFactory.createPipelineServiceClient. |
yan-3005
added
To release
|
Contributor
🟡 Playwright Results — all passed (20 flaky)✅ 3667 passed · ❌ 0 failed · 🟡 20 flaky · ⏭️ 89 skipped
🟡 20 flaky test(s) (passed on retry)
How to debug locally# Download playwright-test-results-<shard> artifact and unzip
npx playwright show-trace path/to/trace.zip # view trace |
mohityadav766
approved these changes
Apr 20, 2026
Contributor
|
Changes have been cherry-picked to the 1.12.6 branch. |
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
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.
Why this change is needed
OpenMetadata uses Flowable as its BPMN workflow engine, which manages its own set of database tables (ACT_RE_, ACT_HI_, etc.) completely separate from the Flyway-managed schema.
Before PR #27234, the webserver initialized WorkflowHandler with DB_SCHEMA_UPDATE_TRUE, which meant Flowable ran its DDL (CREATE TABLE, CREATE INDEX, etc.) every time the server started. If the server crashed mid-startup while DDL was half-complete, some tables would be partially created. On the next restart, Flowable would try to run the same DDL again and blow up on "table already exists" errors, leaving the server unable to start at all.
PR #27234 fixed this in three steps. First, it moved the webserver to DB_SCHEMA_UPDATE_FALSE so Flowable never runs DDL at server startup. Second, it moved Flowable schema initialization into the migrate CLI, which is already the designated place for all database schema work. Third, it wrapped Flowable's DDL in an idempotent layer so that re-running migrate would not fail if the schema was already partially applied.
What the regression was
The migrate CLI now calls WorkflowHandler.initialize(config, true). The WorkflowHandler constructor, regardless of whether it is running in migration or runtime mode, was unconditionally calling initializeExpressionMap, which builds two objects: an IngestionPipelineMapper and a PipelineServiceClient. The PipelineServiceClient is created via reflection using the class name from config.
In the Collate CI environment, the configured PipelineServiceClient class (io.getcollate.clients.pipeline.argo.ArgoServiceClient) is not available on the migrate container's classpath. This caused a ClassNotFoundException wrapped in a PipelineServiceClientException, which propagated out of the migrate command and caused it to exit with code 1. The Flowable schema itself was never the problem and the data migrations had already completed successfully at that point.
What the fix does
The PipelineServiceClient and IngestionPipelineMapper are only needed at workflow execution time, when Flowable resolves BPMN expression variables like ${PipelineServiceClient} in task definitions. During migration, WorkflowHandler only needs to run Flowable's DDL upgrade and then shut down. No BPMN is ever executed.
The fix guards initializeExpressionMap with if (!isMigrationContext) so that in migration mode the expression map is simply left empty. An empty expression map produces a valid DefaultExpressionManager that Flowable accepts without complaint. The schema upgrade runs and completes, and the migrate command exits cleanly.
This follows the same pattern already used elsewhere in the constructor where isMigrationContext controls setAsyncExecutorActivate and setEnableHistoryCleaning.
How to reproduce before this fix
You will see "Running Flowable schema upgrade." followed immediately by the PipelineServiceClientException and exit code 1. After the fix the same command completes with exit code 0.
Test coverage
A new test migrationModeDoesNotLoadPipelineServiceClient was added to WorkflowHandlerSchemaUpdateTest. It configures PipelineServiceClientFactory to throw a RuntimeException simulating a missing class, then calls WorkflowHandler.initialize(config, true) and asserts that it completes without throwing and that createPipelineServiceClient was never called.