In the case https://tempo-io.atlassian.net/browse/TCS-69161, we could see that when having archived projects and Tempo is trying to access information on issues from them, log messages will spam in the Atlassian.log file, eventually impacting the performance and memory usage.
Jhonata Nascimento
| Tempo Products | Tempo Timesheets |
| Tempo Platform | On-Premise |
Regardless of the state of projects, it's related to all projects with no associated permission schemes. It could be even an active project where Tempo spams application logs due to inconsistent project data.
Such cases generally may happen when you attempt to delete a Jira project and deletion happens partially. Yes, it's true that projects sometimes don't get entirely deleted, but their permission schemes might be removed along the way.
Deletion might fail due to any application or system related reasons, and when it fails, most of the project configuration and data will be available except few projects scheme including permission schemes. So what needs to be done is to address the root cause interrupting the deletion job, resolve it and then trigger the the delete project job once again.
Meanwhile, through UI elements, you cannot associate a new permission scheme to any Jira project without any permission scheme, it'll be just a blank page. Maybe it's possible through some Jira api, but there's no guarantee for success here as well.