feat(governance): add id-based workflow instance states endpoint with optional task-transition filter#30164
Conversation
…sition filter
Adds GET /v1/governance/workflowInstanceStates/workflowInstanceId/{workflowInstanceId}
returning the full stage-transition timeline for a workflow instance keyed by UUID.
Why:
- Existing name-based endpoint filters via entityFQNHash(workflowDefinitionName,
instanceId). Renaming a WorkflowDefinition invalidates historical hashes and
silently returns empty results. Id-based query bypasses the hash entirely by
reading the workflowInstanceId column directly.
- Task payloads carry workflowInstanceId (UUID). Callers should not have to
resolve workflowDefinitionId -> name via a second round-trip, and should not
break when a workflow definition is renamed.
Filter:
- Default response returns every stage the workflow entered (generic - works
for any workflow definition).
- Pass onlyTaskTransitions=true to narrow to stages driven by a user-task
transition. Fingerprint: stage.variables contains <stageName>_transitionId,
written by user-task nodes when the user resolves the task. Applies to any
workflow with task nodes; not DAR-specific.
Existing name-based endpoint left unchanged for backwards compatibility.
Tests:
- Unit: WorkflowInstanceStateResourceTest (4 tests: default returns all,
filter narrows, malformed rows filtered without crash, empty result).
- IT: test_WorkflowInstanceStatesByInstanceIdEndpoint in
WorkflowDefinitionResourceIT - spins up a tag-approval workflow, extracts
the resulting task's workflowInstanceId, hits both default and filtered
variants of the id-based endpoint, asserts default == name-based endpoint
and filtered is a strict subset containing only stages with the
<stageName>_transitionId fingerprint.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
❌ PR checklist incompleteThis PR cannot be merged until the following are addressed on its linked issue:
The fields live on the linked issue in the Shipping project (open the issue → right sidebar → Projects). After you set them, re-run this check (or push a commit) — issue/project changes do not re-trigger it automatically. Maintainers can bypass this check by adding the |
|
Hi there 👋 Thanks for your contribution! The OpenMetadata team will review the PR shortly! Once it has been labeled as Let us know if you need any help! |
| assertTrue( | ||
| filteredData.size() > 0, | ||
| "filtered response should include at least the currently-open user-task stage"); | ||
|
|
||
| for (int i = 0; i < filteredData.size(); i++) { |
There was a problem hiding this comment.
Open Task Has No Transition Yet
The test queries the filtered history while approvalTask is still open. Its _transitionId is persisted only when the task is resolved and the stage ends, so the filter removes the only task stage and filteredData is empty. Resolve the task before this request, or expect no task transitions while it remains open.
Context Used: CLAUDE.md (source)
| new OperationContext(Entity.WORKFLOW_DEFINITION, MetadataOperation.VIEW_ALL); | ||
| ResourceContextInterface resourceContext = ReportDataContext.builder().build(); | ||
| authorizer.authorize(securityContext, operationContext, resourceContext); | ||
| List<WorkflowInstanceState> states = repository.listAllStatesForInstance(workflowInstanceId); |
There was a problem hiding this comment.
This endpoint loads and serializes every state for the instance without a limit or time range. A long-running or looping workflow can accumulate enough rows to create a slow response and significant service memory pressure; retain the existing endpoint's pagination or timestamp bounds for this ID-based lookup.
Context Used: CLAUDE.md (source)
Code Review ✅ ApprovedImplements an ID-based lookup for workflow instance states to improve UI timeline rendering and prevent issues with workflow definition renames. The implementation includes an optional task-transition filter and maintains compatibility with the existing name-based endpoint. OptionsDisplay: compact → Showing less information. Comment with these commands to change the behavior for this request:
Was this helpful? React with 👍 / 👎 | Gitar |
Summary
GET /v1/governance/workflowInstanceStates/workflowInstanceId/{workflowInstanceId}— id-based lookup for stage transitions of a single workflow instance.entityFQNHash(workflowDefinitionName, instanceId)and returns empty after a WorkflowDefinition rename. Id-based query bypasses the hash by reading theworkflowInstanceIdcolumn directly (indexed).?onlyTaskTransitions=truenarrows the response to stages driven by a user-task transition (generic across any workflow with task nodes; identified by<stageName>_transitionIdinstage.variables).Why now
UI needs to render an activity timeline on the task detail panel (Requested → Assigned → Approved → Granted → Revoked) from a single API call, without knowing workflow-definition names and without breaking when the definition is renamed. Task payload already carries
workflowInstanceId(UUID) — this endpoint consumes it directly.API contract
onlyTaskTransitions=true: only rows whosestage.variablescontains<stageName>_transitionId. Written by user-task nodes when a user resolves the task.Test plan
mvn -pl openmetadata-service test -Dtest=WorkflowInstanceStateResourceTest→ 4 tests pass.mvn spotless:check -pl openmetadata-service,openmetadata-integration-tests→ clean.test_WorkflowInstanceStatesByInstanceIdEndpointin a stack-up environment.onlyTaskTransitions=truereturns strict subset.🤖 Generated with Claude Code
Greptile Summary
This PR adds direct workflow-instance history lookup with optional task-transition filtering. The main changes are:
Confidence Score: 4/5
The open-task integration path fails before a transition is recorded, and instance history retrieval has no response bounds.
_transitionIdwhile the task is still open.WorkflowDefinitionResourceIT.java and WorkflowInstanceStateResource.java
Important Files Changed
Reviews (1): Last reviewed commit: "Add id-based workflow instance states en..." | Re-trigger Greptile
Context used: