Inconsistent Workflow Cancellation Status Display

[MariusVuscanNx]

Issue: Inconsistent Workflow Cancellation Status Display

Reproduction Steps:

To reproduce the issue, follow these steps:

1. Identify a set of suspended workflow instances.
2. Review the status of these workflows.
3. Initiate cancellation for the selected workflows.
4. Verify the cancellation status in the overview and expect all to be cancelled.

Observed Outcome: After performing the above steps, it was found that 6 workflows were cancelled, while 4 remained in a suspended state.

Upon refreshing the overview page, the statuses updated correctly to reflect the cancellation of all workflows.

Furthermore, it was observed that the API returns the correct number of cancelled workflows, indicating that the backend processes the cancellation requests accurately.

Observations and Proposed Enhancement

The primary issue observed is the inconsistency in the display of workflow cancellation statuses. This inconsistency may lead users to believe that not all selected workflows were successfully cancelled, despite the backend accurately processing all cancellation requests. This discrepancy is due to the immediate server response post-cancellation request, which does not wait for each workflow instance's cancellation process to complete.

Proposed Solution: Introduction of an Interim State

To address this issue, we propose introducing a new InterimState field to the workflow instances, specifically for managing transitional states such as cancellation. When a cancellation request is issued, the InterimState for the affected workflow instances will be set to Cancelling. This state will remain until the cancellation process is fully completed for all workflows, at which point:

• The InterimState field needs to be explicitly cleared once a workflow enters the Cancelled state, ensuring the system accurately reflects the current state without any residual transitional states.

UI Considerations

• Upon executing the cancellation action (potentially in bulk), the UI should immediately reflect the Cancelling interim state for the affected workflows. It is not necessary for the UI to periodically or automatically refresh to update the state changes during the cancellation process.
• Ensuring that the UI displays the Cancelling state provides clear, immediate feedback to users that their request is being processed, without the need for them to manually refresh or question the current state of their workflows.
• A separate issue will be opened to address the need for the Workflow Instances List View to display up-to-date states of workflows, ensuring overall system usability and accuracy in state representation.

By implementing this solution, we aim to significantly improve the feedback and information provided to users during the workflow cancellation process, ensuring that the system's behavior aligns with user expectations and enhances overall usability.

[webbdays]

@sfmskywalker I am wiling to work on this, Please let me know the bounty amount.

[sfmskywalker]

Hi @webbdays , thank you for announcing your interest! We're still working out some of the details of the bounty hunting program, but we'll reach out to you here as soon as it's ready to go.

[webbdays]

ok.

[github-actions[bot]]

⭐ This Issue is Part of the Elsa Workflows Bounty Hunting Program ⭐

Are you ready to contribute and earn rewards for your efforts? This issue offers a bounty for the first eligible contributor who successfully resolves it within the designated time limit, according to our comprehensive program rules.

Before You Start:

• Ensure you have a GitHub account set up to receive payments via GitHub Sponsors.
• Publicly announce your intention to tackle this issue by commenting below. This follows our "First Come, First Served" rule.
• Be aware of the specific time limit for this issue, as failing to submit a solution within this timeframe may open the opportunity for others.

📜 For a detailed overview of participation, submission guidelines, and the process for claiming rewards, please visit our Bounty Hunting Program Guidelines.

To announce your intention to claim this bounty, please comment below. You can use this template:

## Bounty Candidacy Announcement

I am announcing my intention to tackle this bounty issue. Below is my acknowledgment of the key eligibility requirements and rules of the Elsa Workflows Bounty Hunting Program:

- [ ] I have a GitHub account set up for receiving payments via GitHub Sponsors.
- [ ] I understand this issue is assigned on a "First Come, First Served" basis.
- [ ] I am aware of the specific time limit for this issue and commit to submitting my solution within this timeframe.
- [ ] I understand that I must first describe my proposed solution in a comment on this issue or via a discussion linked to this bounty, before starting my work.
- [ ] I have reviewed the [Bounty Hunting Program Guidelines](#5211) in detail.

**GitHub Username**: `YourGitHubUsernameHere`

**Estimated Start Date**: `YYYY-MM-DD`

**Notes/Comments**: `Any additional comments or notes you wish to add`

By checking the boxes above, I signify my understanding and acceptance of the program rules and confirm my intent to proceed with resolving this issue as per the guidelines of the Elsa Workflows Bounty Hunting Program.

We value your contributions to Elsa Workflows and are excited to see the innovative solutions you bring. Let's enhance Elsa Workflows together!