Fixes #22967: move auto-assigned incidents to the Assigned stage

[IceS2]

Fixes #22967

Problem

An incident task created on test failure already inherits its assignees from the test case owners (TestCaseResolutionStatusRepository.createIncidentTask), but TestCaseResolutionTaskWorkflow always enters NewStage and nothing ever advances it — the only edges out of NewStage are the ack/assign/resolve transitions a user fires by hand.

Two symptoms follow from that single cause:

• the incident sits in New even though it has an assignee
• it renders as unassigned, because IncidentTcrsSyncHandler.buildDetailsForStage only attaches assignee details to Assigned records, and the Incident Manager reads the assignee from testCaseResolutionStatusDetails.assignee on the TCRS time series rather than from the task

Fix

After the incident task is created, if assignees resolved, drive the workflow's own assign transition via resolveTaskWithWorkflow — the same path a manual assignment takes. The assign transition targets InProgress, so it takes the non-terminal branch: the workflow advances to AssignedStage, CreateTask stamps workflowStageId=assigned / status=InProgress, and the resulting postUpdate makes the TCRS sync emit an Assigned record carrying the assignee.

Guarded so it only fires when assignees are non-empty, the task actually sits at stage new, and an assign transition is available. Best-effort: an incident that fails to advance is still a usable incident in New, so it never fails test-result ingestion.

Incidents with no owners are untouched and stay in New.

Stage and transition ids of the workflow move into a new IncidentWorkflowStages holder so the TCRS sync handler and this new path cannot drift apart.

InProgress is already in TaskRepository.OPEN_TASK_STATUSES, so incident de-duplication (getOrCreateIncident) and autoCloseIncident both still find the incident after it leaves Open.

Verification

AutoAssignIncidentIT covers both directions — owned test case reaches assigned/InProgress with the owner on the TCRS Assigned record, unowned test case stays new/Open with no Assigned record.

Confirmed end to end against a locally built stack:

owned    -> stage=assigned, status=InProgress, assignees=[owner...]
            TCRS: Assigned(assignee=owner...), New(assignee=None)
unowned  -> stage=new, status=Open, assignees=[]

Known limitation

SetApprovalAssigneesImpl strips the requester from the assignee list to prevent self-approval and does not add them back for workflow-managed tasks. If the user who triggered the test run is the sole owner, the incident ends up unassigned and stays in New — same as a manual assign behaves today. Not addressed here.

Greptile Summary

Adds automatic workflow advancement for newly created incidents that inherit assignees.

• Drives the existing assign transition when an owned incident reaches the new stage.
• Centralizes incident workflow stage and transition identifiers.
• Reuses those identifiers in TCRS synchronization.
• Adds integration coverage for owned and unowned test cases.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/TestCaseResolutionStatusRepository.java	Advances newly created incidents through the existing assignment workflow when inherited assignees are available.
openmetadata-service/src/main/java/org/openmetadata/service/events/lifecycle/handlers/IncidentTcrsSyncHandler.java	Replaces duplicated stage literals with centralized incident workflow identifiers.
openmetadata-service/src/main/java/org/openmetadata/service/tasks/IncidentWorkflowStages.java	Defines shared identifiers for incident workflow stages and the assignment transition.
openmetadata-integration-tests/src/test/java/org/openmetadata/it/tests/AutoAssignIncidentIT.java	Covers assigned workflow and TCRS outcomes for owned incidents and unchanged New behavior for unowned incidents.

Sequence Diagram

sequenceDiagram
  participant Result as Failed test result
  participant Repo as Resolution status repository
  participant Task as Task repository
  participant Workflow as Incident workflow
  participant Sync as TCRS sync handler
  Result->>Repo: Create or find incident
  Repo->>Task: Create incident task
  Task->>Workflow: Start workflow
  alt Assignees resolved and assign is available
    Repo->>Task: Resolve assign transition
    Task->>Workflow: Advance to assigned
    Workflow->>Task: Persist assigned / InProgress
    Task->>Sync: Post-update lifecycle event
    Sync->>Sync: Emit Assigned record with assignee
  else No assignees
    Task->>Sync: Post-create lifecycle event
    Sync->>Sync: Emit New record
  end

Loading

_{Reviews (4): Last reviewed commit: "Merge branch 'main' into fix-incident-sh..." | Re-trigger Greptile}

Context used:

• Knowledge Base — Search Indexing and Event/Notification Sync
• Knowledge Base — Governance Workflows and Applications in OpenMetadata Service

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

✅ PR checks passed

The linked issue has a description and all required Shipping project fields set. Thanks!

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[gitar-bot]

Code Review ✅ Approved 2 resolved / 2 findings

Automatically advances newly created incidents with inherited assignees into the Assigned workflow stage, addressing previous test assertions and async workflow concerns. No issues found.

✅ 2 resolved

✅ Edge Case: Auto-advance silently no-ops if workflow start is async

📄 openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/TestCaseResolutionStatusRepository.java:586-600
advanceAutoAssignedIncident is called synchronously right after createInternal and only fires when the re-fetched task is already at stage new with a populated assign transition (canAdvanceToAssignedStage). This relies on triggerWorkflowManagedTask (Flowable triggerByKey) having synchronously driven the instance to the new user-task stage and persisted workflowStageId/availableTransitions before createInternal returns. If the workflow engine is configured to run asynchronously (async job executor), the task is still at pending-workflow-start at this point, canAdvanceToAssignedStage returns false, and the incident silently stays in New with no error — the fix simply does nothing. Consider documenting/asserting this synchronous-execution assumption, or re-driving the assign after the workflow reaches new via the lifecycle event path rather than inline.

✅ Quality: Fragile assignee assertion via details.toString().contains()

📄 openmetadata-integration-tests/src/test/java/org/openmetadata/it/tests/AutoAssignIncidentIT.java:105-107
The assigned-record assertion checks assigned.getTestCaseResolutionStatusDetails().toString().contains(owner.getName()), matching against the toString() of the whole details object. This is brittle: it can pass on a coincidental substring match anywhere in the serialized blob (e.g. updatedBy, comment) and does not verify the owner is actually in the assignee list. Assert on the typed assignee field of testCaseResolutionStatusDetails (e.g. that its assignee id equals the owner id) for an unambiguous check.

Options

Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar | Powered by Gitar — free for open source}