Skip to content

Conversation

@Zzih96
Copy link
Contributor

@Zzih96 Zzih96 commented Dec 24, 2025

Purpose of the pull request

fix #17817

Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.

(or)

This pull request is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(or)

Pull Request Notice

Pull Request Notice

If your pull request contains incompatible change, you should also add it to docs/docs/en/guide/upgrade/incompatible.md

@SbloodyS SbloodyS changed the title [Fix-17817] [Master]add workflow timeout [Fix-17817] [Master] Fix workflow timeout alerts failed Dec 24, 2025
@SbloodyS SbloodyS added the bug Something isn't working label Dec 24, 2025
@SbloodyS SbloodyS added this to the 3.4.0 milestone Dec 24, 2025
Copy link
Member

@ruanwenjun ruanwenjun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, it's better to add IT case.

* @param modifyBy modifyBy
*/
public void sendWorkflowTimeoutAlert(WorkflowInstance workflowInstance, ProjectUser projectUser) {
public void sendWorkflowTimeoutAlert(WorkflowInstance workflowInstance, ProjectUser projectUser, String modifyBy) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't change this, this PR should only fix the alert bug.

Comment on lines 52 to 55
// Calculate remaining time until timeout: timeout - elapsed time
long delayTime = TimeUnit.MINUTES.toMillis(timeout)
- (System.currentTimeMillis() - workflowInstance.getStartTime().getTime());
// Ensure delayTime is not negative (trigger immediately if already timeout)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not clear in which case the delayTime might be negative, since System.currentTimeMillis() - workflowInstance.getStartTime().getTime() should always > 0.

Comment on lines 63 to 65
private void doWorkflowTimeoutAlert(final WorkflowInstance workflowInstance) {
// ProjectUser will be built in WorkflowAlertManager
workflowAlertManager.sendWorkflowTimeoutAlert(workflowInstance, null);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should fix like #17818, otherwise will throw NPE

@SbloodyS SbloodyS modified the milestones: 3.4.0, 3.4.1 Jan 5, 2026
@ruanwenjun ruanwenjun force-pushed the add_workflow_timeout branch from 8e10927 to 3de2674 Compare January 8, 2026 13:00
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In our environment, we've already resolved the task timeout alerts and workflow timeout alerts. Here's how I determine whether a workflow has completed:

final IWorkflowExecutionGraph workflowExecutionGraph = workflowExecutionRunnable.getWorkflowExecutionGraph();
if (workflowExecutionGraph.isAllTaskExecutionRunnableChainFinish()) {
// all the TaskExecutionRunnable chain in the graph is finish, means the workflow is already finished.
return;
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isFinalState() reflects the persistent final state, making it more reliable. isAllTaskExecutionRunnableChainFinish(), on the other hand, only reflects the task completion state in memory; it may not yet have transitioned to the final workflow state.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isFinalState() reflects the persistent final state, making it more reliable. isAllTaskExecutionRunnableChainFinish(), on the other hand, only reflects the task completion state in memory; it may not yet have transitioned to the final workflow state.

In my opinion, If the workflow is already in a completed state in memory, does that mean timeout handling is no longer meaningful?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Being equal to zero doesn't seem reasonable either.

final int timeout = workflowInstance.getTimeout();
checkState(timeout > 0, "The workflow timeout: %s must >0 minutes", timeout);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it shouldn't be 0, but I need to double-check.

@Zzih96
Copy link
Contributor Author

Zzih96 commented Jan 9, 2026

@ruanwenjun I've already modified it as requested. Could you please check it again?

Copy link
Member

@ruanwenjun ruanwenjun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please removed the UT, this kind of ut help little, we should add IT case.

final WorkflowInstance workflowInstance = workflowExecutionRunnable.getWorkflowInstance();
final String workflowName = workflowExecutionRunnable.getName();

// Check if workflow is still active (not finished)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Check if workflow is still active (not finished)

Comment on lines +59 to +63
// Check if warning group is configured
if (workflowInstance.getWarningGroupId() == null) {
log.info("Skipped sending timeout alert for workflow {} because warningGroupId is null.", workflowName);
return;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Check if warning group is configured
if (workflowInstance.getWarningGroupId() == null) {
log.info("Skipped sending timeout alert for workflow {} because warningGroupId is null.", workflowName);
return;
}

If the warningGroupIf is null, don't create event.

import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
class WorkflowTimeoutLifecycleEventHandlerTest {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this UT.

import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
class WorkflowStartLifecycleEventHandlerTest {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this UT.

import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
class WorkflowTimeoutLifecycleEventTest {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this UT.

@sonarqubecloud
Copy link

Please retry analysis of this Pull-Request directly on SonarQube Cloud

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backend bug Something isn't working test

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] [Master] Missing workflow timeout alerts

4 participants