fix(archives): metadata labels may be set during upload

[lkonno]

Fixes #1045

The labels are set to the archived recording when "metadata" in JSON (e.g.: {"reason":"test","reason1":"test1"}) containing the labels is sent along to the uploaded file.

[andrewazores]

There is a failing unit test that needs correcting or updating. Also, I think you will need to run mvn spotless:apply to apply automatic source code formatting.

How do I test this manually? I tried with ex.

$ curl -k -v -X POST --header "Authorization: Basic $(echo user:pass | base64)" -F recording=@$HOME/Downloads/es-andrewazor-demo-Main_foo_20220913T134900Z.jfr https://localhost:8181/api/v1/recordings -F metadata='{"labels":{"foo":"bar"}}'

and the request seems to hang. If I Ctrl-C the request then I can see that the recording file actually does exist in the archives but it does not have the metadata labels set.

[lkonno]

To test it use:

$ curl -k -v -X POST --header "Authorization: Basic $(echo user:pass | base64)" -F recording=@$HOME/Downloads/es-andrewazor-demo-Main_foo_20220913T134900Z.jfr https://localhost:8181/api/v1/recordings -F metadata='{"foo":"bar"}'

Or multiple labels:

$ curl -k -v -X POST --header "Authorization: Basic $(echo user:pass | base64)" -F recording=@$HOME/Downloads/es-andrewazor-demo-Main_foo_20220913T134900Z.jfr https://localhost:8181/api/v1/recordings -F metadata='{"foo":"bar","foo1":"foo1"}'

I tested it from web-client editing the Api.services.tsx with:

  uploadRecording(file: File, labels: RecordingLabel[], signal?: AbortSignal): Observable<string> {
    window.onbeforeunload = () => true;
    return this.login.getHeaders().pipe(
      concatMap(headers => {
        const body = new window.FormData();
        body.append('recording', file);
        body.append('metadata', this.stringifyRecordingLabels(labels));

[andrewazores]

Ah okay nice, that curl command worked! I had assumed that the nested labels object was required, but I was wrong. However, when I do that, I think that should either be ignored or result in a 400 response - it seems to just silently hang. I inserted some logger lines to see what's happening and it looks like the parseRecordingLabels call may be the culprit.

[andrewazores]

Also using httpie, https -f -vv :8181/api/v1/recordings Authorization:"Basic $(echo user:pass | base64)" metadata='{"foo":"bar"}' recording@$HOME/Downloads/es-andrewazor-demo-Main_foo_20220913T134900Z.jfr works too. Nice.

[lkonno]

Regarding the field name to input the labels, I think that using metadata can be confusing, so I am changing the name to labels.

$ curl -k -v -X POST --header "Authorization: Basic $(echo user:pass | base64)" -F recording=@$HOME/Downloads/es-andrewazor-demo-Main_foo_20220913T134900Z.jfr https://localhost:8181/api/v1/recordings -F labels='{"foo":"bar"}'

[lkonno]

• Invalid labels format now returns Bad Request and do not upload the recording file;
• Fixed the test to check the metadata in the response;
• The request now uses labels field name instead of metadata which is a not required field.

[andrewazores]

Great work, thanks. The implementation looks good and works nicely in manual testing now. The updated test case looks good, too. Could you add a few more tests? Right now the unit test is only exercising the one case where the labels attribute is provided and has valid contents. I'd like to see a test that includes no labels and a few different cases where labels are invalid in various ways.

[lkonno]

shouldHandleRecordingUploadRequest --> upload containing no labels
shouldHandleRecordingUploadRequestWithLabels --> Created to handle upload containing valid labels
shouldHandleInvalidLabels --> Created to handle invalid labels