Mark project as not required and only validate when specified.

[Zusel]

Description

"Hey, so after our little chat, I thought I'd just quickly add it myself. My thinking behind it was that I'd simply check whether the component's project and the (optional) project match. That way we can resolve the 500 and also get users used to the idea that the project field will go away entirely. With the conflict, we can then prevent someone (like me) from wondering why what they expected isn't happening :)

Addressed Issue

#6561

Additional Details

Checklist

• I have read and understand the contributing guidelines (No 404 not found)
• This PR fixes a defect, and I have provided tests to verify that the fix is effective (no)
• This PR implements an enhancement, and I have provided tests to verify that it works as intended (no)
• This PR introduces changes to the database model, and I have updated the migration changelog accordingly (no)
• This PR introduces new or alters existing behavior, and I have updated the documentation accordingly (cant find any docs)
• This PR is a substantial change (per the ADR criteria), and I have added an ADR under docs/adr/ (no)

[owasp-dt-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 1 duplication

Metric	Results
Complexity	0
Duplication	1

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[nscuro]

Thanks for the PR!

I get the intention behind failing for inconsistent project <-> component parameters, but it will cause all existing clients to break that did not consider this. The previous behavior was mostly harmless because what mattered has always been the component parameter. Turning that into an error is quite blunt and not appropriate for a patch version.

I'd suggest we just follow what 0dbe529 (v5) did:

• Ignore the project parameter entirely
• Deprecate the project parameter so it becomes visible in the OpenAPI spec:

  dependency-track/apiserver/src/main/java/org/dependencytrack/resources/v1/vo/AnalysisRequest.java

  Lines 40 to 43 in 157afd3

  	/**
  	* @deprecated The project is inferred from {@link #component}. This value is ignored.
  	*/
  	@Deprecated(since = "5.0.0", forRemoval = true)

[Zusel]

Heyho,
I get the point that throwing a 409 might be a bit dramatic and that it will/could break some things. Still, I think just deprecating it is the wrong way to go. Nobody notices that this field is deprecated — you'd have to actually read the code for that, and normally you don't. Besides, the 409 only occurs if you specify a projectId and then hit the wrong project. If someone doesn't:

• specify the wrong project
• specify a project at all

then it will never affect them.
So I really do consider it very, very important that this is handled cleanly. Because if you're interacting with the REST API here and your vulnerability collection suddenly gets edited completely wrong, I'd consider that CRITICAL. You could easily destroy your entire vulnerability inventory this way.
Maybe a bit dramatic for a patch update, but I consider it necessary.