flowers-59f opened a new issue, #12104: URL: https://github.com/apache/inlong/issues/12104
### What happened ### Description When deleting the data flow group, the related data in the tables schedule_config and inlong_stream did not perform the logical deletion correctly. ### Phenomenon **Create a data flow group** <img width="1270" height="215" alt="Image" src="https://github.com/user-attachments/assets/30ce0dbb-79f7-4539-b87f-4ac818db0cb9"; /> **Relevant data** <img width="930" height="238" alt="Image" src="https://github.com/user-attachments/assets/07991fee-63f7-42b0-a107-f070c9d8cd34"; /> <img width="604" height="213" alt="Image" src="https://github.com/user-attachments/assets/c56bb91a-bee5-487c-b700-dd72ef6ad1b5"; /> <img width="611" height="196" alt="Image" src="https://github.com/user-attachments/assets/1a1d8a2a-3576-4a16-9530-202fb6a1196b"; /> **Delete this data flow group** <img width="1329" height="399" alt="Image" src="https://github.com/user-attachments/assets/3fb3ed25-f99b-4504-b83e-dab6cefb5424"; /> <img width="926" height="230" alt="Image" src="https://github.com/user-attachments/assets/12421c89-304a-412d-8288-5728d0f6495c"; /> <img width="600" height="236" alt="Image" src="https://github.com/user-attachments/assets/fc1fe8d2-64a3-4d3b-8d0d-53db3247da13"; /> <img width="615" height="235" alt="Image" src="https://github.com/user-attachments/assets/a6865d2b-e1e0-4471-9e04-8984ee4df39d"; /> It can be seen that the relevant data under the "schedule_config" and "inlong_stream" tables have not correctly performed logical deletion, because the "is_deleted" field of the relevant data was not updated. This issue will cause problems when creating a data flow group with the same name again after deleting an existing data flow group.This is also the situation in which I discovered this problem. ### What you expected to happen I think the main problem lies in InlongGroupServiceImpl.delete(...). The deletion process is roughly as follows: InlongGroupController.delete(...) ->InlongGroupProcessService.deleteProcess(...) ->InlongGroupProcessService.invokeDeleteProcess(...) ->workflowService.start(ProcessName.DELETE_GROUP_PROCESS, ...); This workflow will create and invoke UpdateGroupListener and updateGroupCompleteListener (The UpdateGroupFailedListener will only be invoked when the pre-deletion operation fails). In the UpdateGroupListener, the status of the group was updated. ```java case DELETE: groupService.updateStatus(groupId, GroupStatus.CONFIG_DELETING.getCode(), operator); ``` After the pre-deletion operation is completed, the updateGroupCompleteListener deletes the relevant information and updates the status. ```java case DELETE: // delete process completed, then delete the group info groupService.delete(groupId, operator); ``` There are certain issues with the groupService.delete(...) . ```java if (GroupStatus.allowedDeleteSubInfos(GroupStatus.forCode(entity.getStatus()))) { streamService.logicDeleteAll(groupId, operator); } public static boolean allowedDeleteSubInfos(GroupStatus status) { return status == GroupStatus.TO_BE_SUBMIT || status == GroupStatus.APPROVE_REJECTED || status == GroupStatus.CONFIG_DELETED; } ``` At this point, the status of the group is CONFIG_DELETING, which is not within the permitted states. Therefore, the streamService.logicDeleteAll(...) method will not be executed. Then the status of InlongGroupEntity was updated. ```java entity.setIsDeleted(entity.getId()); entity.setStatus(GroupStatus.CONFIG_DELETED.getCode()); entity.setModifier(operator); int rowCount = groupMapper.updateByIdentifierSelective(entity); if (rowCount != InlongConstants.AFFECTED_ONE_ROW) { LOGGER.error("inlong group has already updated for groupId={} curVersion={}", groupId, entity.getVersion()); throw new BusinessException(ErrorCodeEnum.CONFIG_EXPIRED); } ``` However, this update operation should be carried out after the completion of the latter two deletion operations. ```java // logically delete the associated extension info groupExtMapper.logicDeleteAllByGroupId(groupId); // remove schedule if (DATASYNC_OFFLINE_MODE.equals(entity.getInlongGroupMode())) { try { scheduleOperator.deleteByGroupIdOpt(entity.getInlongGroupId(), operator); } catch (Exception e) { LOGGER.warn("failed to delete schedule info for groupId={}, error msg: {}", groupId, e.getMessage()); } } ``` Because the corresponding SQL for groupExtMapper.logicDeleteAllByGroupId(...) is as follows ```sql <update id="logicDeleteAllByGroupId"> update inlong_group_ext set is_deleted = id where inlong_group_id = #{groupId, jdbcType=VARCHAR} and is_deleted = 0 </update> ``` scheduleOperator.deleteByGroupIdOpt(...) will eventually call ScheduleServiceImpl.deleteByGroupId(...). The SQL statement used to query the relevant scheduleEntity is as follows: ```sql <select id="selectByGroupId" parameterType="java.lang.String" resultMap="BaseResultMap"> select <include refid="Base_Column_List"/> from schedule_config where inlong_group_id = #{inlongGroupId,jdbcType=VARCHAR} and is_deleted = 0 </select> ``` Both of the above SQL statements require that is_deleted = 0, but this value has already been updated earlier. ### How to reproduce 1. Create a data flow group 2. Delete it and check the database 3. You can also create another data stream group with the same name, it will result in an error. ### Environment _No response_ ### InLong version 2.3.0 ### InLong Component InLong Manager ### Are you willing to submit PR? - [x] Yes, I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
