[INLONG-12104][Manager] Fix failure to logically delete associated data for data flow groups

[flowers-59f]

Fixes #12104

Motivation

This PR ensures that when a data flow group is removed, all its associated records are deleted simultaneously.

Modifications

1. Change the status of the group to "GroupStatus.CONFIG_DELETED" in advance
2. Move the update operation of the data stream group after the last two deletion operations

Verifying this change

• This change added tests and can be verified as follows:
  I didn't write unit tests, but conducted a front-end and back-end integration test.
  The results are as follows:

Create a data flow group

Relevant data

After deletion

The "is_deleted" field of the relevant data can be correctly modified.

Documentation

• Does this pull request introduce a new feature? (no)

[fuweng11]

The status check is essential and cannot be removed, as the deletion process involves asynchronous operations that interact with the Agent and sort. If the deletion command is executed repeatedly during this process, due to asynchronous operations, the Agent or sort task may make incorrect judgments. For instance, if a deletion is performed immediately after the Agent has just been issued a collection task, the requests received by the Agent may originate from different managers, temporarily causing data inconsistency. At this time, the order in which the Agent receives task deletion or addition commands may be inconsistent, leading to task anomalies.

[flowers-59f]

The status check is essential and cannot be removed, as the deletion process involves asynchronous operations that interact with the Agent and sort. If the deletion command is executed repeatedly during this process, due to asynchronous operations, the Agent or sort task may make incorrect judgments. For instance, if a deletion is performed immediately after the Agent has just been issued a collection task, the requests received by the Agent may originate from different managers, temporarily causing data inconsistency. At this time, the order in which the Agent receives task deletion or addition commands may be inconsistent, leading to task anomalies.

Then, when executing these deletion functions, can we check the current status and skip the status validation if it's already "GroupStatus.CONFIG_DELETING"? Or is there a better solution?

[fuweng11]

The status check is essential and cannot be removed, as the deletion process involves asynchronous operations that interact with the Agent and sort. If the deletion command is executed repeatedly during this process, due to asynchronous operations, the Agent or sort task may make incorrect judgments. For instance, if a deletion is performed immediately after the Agent has just been issued a collection task, the requests received by the Agent may originate from different managers, temporarily causing data inconsistency. At this time, the order in which the Agent receives task deletion or addition commands may be inconsistent, leading to task anomalies.

Then, when executing these deletion functions, can we check the current status and skip the status validation if it's already "GroupStatus.CONFIG_DELETING"? Or is there a better solution?

Given that the following code is only referenced by group.delete, you can add "GroupStatus.CONFIG_DELETING" to this status check, or it is better to modify the group status to "GroupStatus.CONFIG_DELETED" before performing this status check
if (GroupStatus.allowedDeleteSubInfos(GroupStatus.forCode(entity.getStatus()))) { streamService.logicDeleteAll(groupId, operator); }

[flowers-59f]

The status check is essential and cannot be removed, as the deletion process involves asynchronous operations that interact with the Agent and sort. If the deletion command is executed repeatedly during this process, due to asynchronous operations, the Agent or sort task may make incorrect judgments. For instance, if a deletion is performed immediately after the Agent has just been issued a collection task, the requests received by the Agent may originate from different managers, temporarily causing data inconsistency. At this time, the order in which the Agent receives task deletion or addition commands may be inconsistent, leading to task anomalies.

Then, when executing these deletion functions, can we check the current status and skip the status validation if it's already "GroupStatus.CONFIG_DELETING"? Or is there a better solution?

Given that the following code is only referenced by group.delete, you can add "GroupStatus.CONFIG_DELETING" to this status check, or it is better to modify the group status to "GroupStatus.CONFIG_DELETED" before performing this status check if (GroupStatus.allowedDeleteSubInfos(GroupStatus.forCode(entity.getStatus()))) { streamService.logicDeleteAll(groupId, operator); }

I think it would be a good approach to change the status of the group to "GroupStatus.CONFIG_DELETED" in advance. Issues caused by the status check during streamService.logicDeleteAll(...) will also be resolved. But which of the following two positions is better for updating this status?
UpdateGroupCompleteListener.listen(...)

case DELETE:  
    // delete process completed, then delete the group info  
    // first position
    groupService.delete(groupId, operator);  
    break;

Because there are no transactions, if the status is changed in the first position, problems may arise if an exception occurs during the subsequent execution process.

InlongGroupServiceImpl.delete(...)

// second position
// before deleting an inlong group, delete all inlong streams, sources, sinks, and other info under it  
if (GroupStatus.allowedDeleteSubInfos(GroupStatus.forCode(entity.getStatus()))) {  
    streamService.logicDeleteAll(groupId, operator);  
}

I think it would be better to make the group status change at the second position. However, in this case, the subsequent judgment would lose its significance.

[fuweng11]

lowedDeleteSubInf

Suggested modifications are as follows:
case DELETE: // delete process completed, then delete the group info groupService.updateStatus(groupId, GroupStatus.CONFIG_DELETED.getCode(), operator); groupService.delete(groupId, operator); break;

[fuweng11]

lowedDeleteSubInf

Suggested modifications are as follows:
case DELETE: // delete process completed, then delete the group info groupService.updateStatus(groupId, GroupStatus.CONFIG_DELETED.getCode(), operator); groupService.delete(groupId, operator); break;

[flowers-59f]

Suggested modifications are as follows:
case DELETE: // delete process completed, then delete the group info groupService.updateStatus(groupId, GroupStatus.CONFIG_DELETED.getCode(), operator); groupService.delete(groupId, operator); break;

OK, thank you very much, I will modify my code.