muzamilkm opened a new issue, #9081:
URL: https://github.com/apache/devlake/issues/9081

   ### Search before asking
   
   - [x] I had searched in the 
[issues](https://github.com/apache/incubator-devlake/issues?q=is%3Aissue) and 
found no similar issues.
   
   
   ### What happened
   
   The generic `DELETE /projects/:projectName` endpoint deletes a project 
through `services.DeleteProject()` without exposing a lifecycle hook for 
plugins or features that maintain project-scoped state.
   
   Core DevLake records such as the project, blueprint, mappings and metric 
settings are cleaned up, but feature-owned records can be left stale if their 
cleanup normally happens through a feature-specific or Config UI deletion flow.
   
   There is already a project lifecycle extension for renames through 
`ProjectService.RenameProject(...)`, but there is no equivalent hook for 
deletion.
   
   ### What do you expect to happen
   
   Project deletion should provide a lifecycle extension point that allows 
plugins or features with project-scoped state to validate and clean up their 
own records before the project is deleted.
   
   Ideally this should integrate with the core deletion transaction where 
possible so project deletion and feature-owned cleanup cannot leave 
inconsistent state.
   
   For example, the existing `ProjectService` boundary could expose a 
`BeforeDeleteProject` or `DeleteProject` hook similar to `RenameProject`.
   
   ### How to reproduce
   
   1. Add or use a feature/plugin that persists a record associated with a 
DevLake project and normally removes or validates that record during its own 
project-deletion flow.
   2. Create a DevLake project and associate feature-owned state with it.
   3. Delete the project directly through:
   
      DELETE /projects/:projectName
   
   4. Observe that `server/api/project.DeleteProject` calls 
`services.DeleteProject(projectName)` directly.
   5. Observe that core project records are removed, but no plugin/feature 
deletion hook is invoked.
   6. The feature-owned project association can therefore remain stale or 
orphaned.
   
   This is reproducible on current `main` at commit:
   
   f110addad86930c4c792a3d22051e922346f3656
   
   ### Anything else
   
   _No response_
   
   ### Version
   
   f110addad86930c4c792a3d22051e922346f3656
   
   ### 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]

Reply via email to