Fix submissionEnvelopes/search/findByUuid endpoint

[jacobwindsor]

Fix issue where findByUuid wasn't working, causing the state tracker to fail.

See Slack thread

[jacobwindsor]

The change that stopped this endpoint from working was here I think. Seems unlikely that that is what has caused the issue as was so long ago

[yusra-haider]

This is going to cause an issue on the UI, in the submission detail view:

{"url":"http://localhost:8080/submissionEnvelopes/search/findByUuidUuid","exceptionMessage":"Resource not found!"}

because of how this core api endpoint is consumed here:
https://github.com/ebi-ait/ingest-ui/blob/9d6b208d7479eaec451fa331c40e2af49ca7a922/client/src/app/shared/services/ingest.service.ts#L96

is it possible to update the api endpoint in state tracker instead of core?

[amnonkhen]

Why does Uuid appear twice in the method name?

[amnonkhen]

Probably because of the non-exported findByUuid method?

[MightyAx]

A bit of a late response here but i can explain, this is due to the automated spring mongo methods interacting with our Uuid class.

SubmissionEnvelope extends AbstractEntity which contains the uuid property of type Uuid from org.humancellatlas.ingest.core.Uuid.
The Uuid class contains a single property uuid of type UUID from java.util.UUID.

So using a snippet of this example, you can see that the uuid property of the submissionEnvelope is an object containing a uuid property.
GET /submissionEnvelopes/6080a6a1dd9aab1232d308b0

{
  "submissionDate" : "2021-04-21T22:26:41.995Z",
  "updateDate" : "2021-04-22T00:07:18.005Z",
  "user" : "601c2af3ac1792031eee4261",
  "lastModifiedUser" : "anonymousUser",
  "type" : "Submission",
  "uuid" : {
    "uuid" : "9262e9bf-5ebd-44ee-b80f-15cf107b32a5"
  },
  "events" : [ ]
}

So when using mongo spring repositories, the name of the method reflects where the data is being pulled from the source document.
The non-exported findByUuid method would be used with an object containing a uuid property:

uuid_object = {"uuid": "9262e9bf-5ebd-44ee-b80f-15cf107b32a5"}
envelope = submissionEnvelopeRepository.findByUuid(uuid_object);

whereas the second method just takes the UUID, which is more usable in our rest api, Hal browser, called from ingest UI.

uuid = "9262e9bf-5ebd-44ee-b80f-15cf107b32a5"
envelope = submissionEnvelopeRepository.findByUuidUuid(uuid);

In common language whenever anyone on the team talks about the uuid they mean this "9262e9bf-5ebd-44ee-b80f-15cf107b32a5" but actually in our code that is the Uuid of the Uuid.

Why do we have a custom Uuid class? I don't know.

[jacobwindsor]

@ebi-ait/hca-dev we don't need this anymore right? Shall I close it?

[aaclan-ebi]

Would still be nice to merge, we just need to make sure if the findByUuidUuid usage is replaced.

• UI
• archiver?
• exporter?

[MightyAx]

To make this fix easier to merge we can expose the findbyUuidUuid method at both:
submissionEnvelopes/search/findByUuid &
submissionEnvelopes/search/findByUuidUuid

1. Which would allow us to merge this change without changing downstream components.
2. Then change the consuming components to use findByUuid
3. Then make a new change here to remove the redundant findByUuidUuid