Incorrect API response from GET /api/v1/project/{id} following a specific sequence of API calls

[michal-futurice]

Current Behavior

Dependency-Track returns an incorrect response body when creating and reading a project with a parent via the API with the following sequence of calls:

1. PUT /api/v1/project to create a parent project (that itself has no parent)
2. PUT /api/v1/project to create a child project (that has the project from step 1 as its parent)
3. GET /api/v1/project/{parentId}
4. GET /api/v1/project/{childId}

In this sequence the response from step (3) correctly identifies the child in the children field (responses prettified for readibility):

{
  "name": "test-parent-project",
  "classifier": "APPLICATION",
  "uuid": "75895014-82c1-466b-98ea-100514a587b2",
  "children": [
    {
      "name": "test-child-project",
      "classifier": "APPLICATION",
      "uuid": "4c5fa8d4-6244-4d25-bf71-ead6c820ebd1",
      "parent": {
        "name": "test-parent-project",
        "uuid": "75895014-82c1-466b-98ea-100514a587b2"
      },
      "active": true
    }
  ],
  "properties": [],
  "tags": [],
  "active": true,
  "versions": [
    {
      "uuid": "75895014-82c1-466b-98ea-100514a587b2"
    }
  ]
}

But the response from (4) contains a malformed field "parent":{} instead of a reference to the parent:

{
  "name": "test-child-project",
  "classifier": "APPLICATION",
  "uuid": "4c5fa8d4-6244-4d25-bf71-ead6c820ebd1",
  "parent": {},
  "children": [],
  "properties": [],
  "tags": [],
  "active": true,
  "versions": [
    {
      "uuid": "4c5fa8d4-6244-4d25-bf71-ead6c820ebd1"
    }
  ]
}

The ordering of calls is important. Exchanging the order of steps (3) and (4) (i.e. getting the child after its created before getting its parent) fixes this problem, apparently for all subsequent calls like (4).

We've also noticed another effect: the GET parent project response has no parent field at all before the child is created. But after the child is created the response contains a correctly formed parent field pointing back to the parent. We're not sure whether this is a second defect (and which of the two ways is correct), or by design.

Steps to Reproduce

1. The attached script can be reviewed and then used to (hopefully) replicate the problem and test various call orderings.

This was tested on a dockerized DT started from a docker compose file consistent with https://dependencytrack.org/docker-compose.yml (no changes to the configuration of those two containers).

cause-bug.sh.gz

Expected Behavior

Responses from GET /api/v1/project/{projectId} should correctly identify the parent project or lack thereof regardless of API call order.

Dependency-Track Version

4.11.4

Dependency-Track Distribution

Container Image

Database Server

N/A

Database Server Version

No response

Browser

N/A

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported

[nscuro]

Thanks for the detailed reproduction steps! I was able to reproduce this with v4.11.x, but not with v4.12.0-SNAPSHOT (current master).

I suspect that this change in Alpine 3.0.0 (which is what DT v4.12 is based on) had something to do with it.

Previously, objects were reloaded from the database immediately after they've been persisted. That means that the object instance being returned to the API did not necessarily have the same fields loaded, that the persisted instance had.

I'll add a regression test case for this specific scenario.

[github-actions]

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.