RockteMQ-AI commented on issue #2747: URL: https://github.com/apache/rocketmq-dashboard/issues/2747#issuecomment-5461471787
**Issue Evaluation** Category: `bug` | Status: **Confirmed** The reported issue has been verified against the current codebase. **Root Cause:** In `CloudCredentialService.java:123-139`, the `delete(Long id)` method performs a check-then-act pattern without transactional protection: 1. `instanceRepository.existsByCredentialId(id)` — checks if any instance references the credential 2. `credentialRepository.deleteById(id)` — deletes the credential These are separate operations without a shared lock or database foreign key constraint. Concurrently, `InstanceService.createInstance()` and `importCloudInstances()` can create instances referencing a credential between the check and the delete, leaving orphaned references. The `instanceRepository.existsByCredentialId()` implementation (MybatisPlusInstanceRepository:139-144) uses a simple `SELECT COUNT(*)` query, which provides no locking guarantee. **Impact:** Data integrity — instances may reference deleted credentials under concurrent access. **Severity:** Medium — requires specific timing to trigger, but can cause confusing errors for users. **Suggested fix directions:** - Add a database foreign key constraint from `rmq_instance.credential_id` to the credential table - Or use `SELECT ... FOR UPDATE` to lock the credential row during the delete transaction - Or implement optimistic locking with a version column An automated fix proposal can be generated. Reply `/approve` to proceed with PR generation. --- *Automated evaluation by RockteMQ-AI* -- 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]
