404 for components when opening project page #2315
Comments
|
We noticed this also before when we worked on the dependency-tree. In our case it always happened when some kind of error disrupted the BOM processing, which sometimes lead to the "directDependencies" field of a project not being updated when a BOM was processed. If the BOM contained less components than the one before, the directDependencies had still references to no longer existing elements. This was the case already in 4.6.x, but only happens in very special conditions from what we saw. we couldn't really find the root cause or a suitable fix in the short analysis we did. I think this is the same problem. |
|
After first encountering the issue I tried updating dependency track and restarted the docker containers for that. I don't think the logs are persistent, so I can't check them now, but I don't remember seeing any. We changed the tool for generating the BOM, which certainly could explain one or two dependencies disappearing, or getting tracked under a different name/id. I just triggered the CI job again for the first project that got 'fixed' by downloading the BOM and I see some errors in the apiserver log, but no 404 requests. If this doesn't help I will see whether I can reproduce the two BOMs that triggered the bug when uploaded in successive order. E: |
This is something that would happen a LOT in practice, especially in projects in DT that are used to track work in progress. In fact, the disappearance of components between one BOM upload and the next can be argued to show that DT is proving to be useful! Just today we had one project where a (vulnerable) component vanished from the BOM because the vulnerability in DT drew attention to the presence of the component... and the solution was to exclude it from the POM because it simply was not needed. |
Yes, but it only appears to be a problem (in the case we saw) if the BOM upload produced an error during processing. Because the directDependencies are updated last and if anything fails before it just doesn't happen, even though components might be deleted by processing step already. So if everything works fine there shouldn't be an issue. Someone with a bit deeper knowledge of the processing should look into this. Fact is, in some cases the directDependency field is out of sync. |
|
We currently generate SBOMs with CycloneDX and upload them to Dependency Track using a cron job. Without running into any errors on the backend, we still often see missing components giving a 404 in the UI. Seven months later, are there any prospects for a fix (e.g. avoiding rendering components that don't exist)? |
|
Hi Same problem here. SBOM was correctly created and uploaded correctly. No errors in logs, but in some cases with random projects, when showing project information, the same 404 errors trying to get api/v1/component/?includeRepositoryMetaData=true |
|
I think this issue was caused due to the fact that the dependency graph is processed before components are "reconciled" (i.e. components found to no longer be present in the project are removed). So theoretically, it could happen that components are removed that are referenced as "direct dependency" by others. I am not 100% certain how this can be reproduced, but I am very optimistic that it's going to be resolved by #3357. The dependency graph is now processed last, so there's a less likely chance of this scenario happening. For each entry in the graph, we check if the component actually exists. Also, the entire operation is now atomic, so even if BOM processing fails halfway, it will not cause an inconsistent state to be left behind. |
nscuro
added
p2
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Current Behavior
hi,
After successfully uploading a BOM through the Jenkins plugin, the project page in the frontend throws a few http 404 errors for some of the components.
The requests themself look like this:
api/v1/component/<UUID>with<UUID>being seemingly random, but persistent between requests of project page. The UUIDs don't show up in the COMPONENT table of the database.When opening the project page and triggering the 404s nothing is being logged in the api servers docker log. The projects themself are written in javascript and have a large number of components (~1000).
In one case a coworker was able to fix the issue by manually downloading the BOM through the frontend.
Steps to Reproduce
Expected Behavior
NO API errors
Dependency-Track Version
4.7.0
Dependency-Track Distribution
Container Image
Database Server
PostgreSQL
Database Server Version
13.9
Browser
Mozilla Firefox
Checklist
The text was updated successfully, but these errors were encountered: