Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Harmony 1894 - add support for labeling jobs #630

Merged
merged 9 commits into from
Sep 27, 2024
Merged

Harmony 1894 - add support for labeling jobs #630

merged 9 commits into from
Sep 27, 2024

Conversation

indiejames
Copy link
Contributor

@indiejames indiejames commented Sep 26, 2024

Jira Issue ID

HARMONY-1894

Description

Adds a new parameter label that can be provided with Harmony requests (OGC Coverages/EDR) to specify one ore more labels for a job.

Local Test Steps

  1. Check out this branch
  2. Run the migrations or run bin/bootstrap-harmony which will run the migrations for you
  3. Include one or more labels with a Harmony request
    For Coverages:
curl -Ln -bj "http://localhost:3000/C1233800302-EEDTEST/ogc-api-coverages/1.0.0/collections/red_var,blue_var,green_var/coverage/rangeset/?subset=lat(20%3A60)&subset=lon(-140%3A-50)&outputCrs=EPSG%3A31975&format=image%2Fpng&maxResults=1&label=Foo,baR"

For EDR (GET):

curl -Ln -bj "http://localhost:3000/ogc-api-edr/1.1.0/collections/C1234208438-POCLOUD/area?maxResults=1&parameter-name=all&coords=POLYGON%20%28%28-164.8%2032.3%2C%20-179.3%2025.2%2C%20-165.5%2018.3%2C%20-164.8%2032.3%29%29&labels=abc,123"

For EDR (POST):

curl --request POST \
        --url http://localhost:3000/ogc-api-edr/1.1.0/collections/C1233800302-EEDTEST/position \
        --header "Authorization: Bearer $MY_UAT_TOKEN" \
        --header 'Content-Type: application/json' \
        --data '{
    "coords": "POINT(-40 10)",
    "granuleId": ["G1233800343-EEDTEST"],
    "parameter-name": [
      "all"
    ],
    "crs": "EPSG:31975",
    "f": "image/png", "label": ["abc😡123","Fu#bar"]
  }'
  1. Check the database tables labels and job_labels and make sure you see rows for the labels you set.
    Here are a couple of useful queries (change the labels to whatever you used):
select "j"."jobID" from jobs j JOIN jobs_labels l ON "j"."jobID" = l.job_id JOIN labels ul ON l.label_id = ul.id WHERE ul.value = 'fizz';
select "j"."jobID" from jobs j JOIN jobs_labels l ON "j"."jobID" = l.job_id JOIN labels ul ON l.label_id = ul.id WHERE ul.value = 'abc😡123';

PR Acceptance Checklist

  • Acceptance criteria met
  • Tests added/updated (if needed) and passing
  • Documentation updated (if needed)

* @param labels - the array of strings representing the labels. These will be forced to lower-case.
* If this is an empty array then any existing labels for the job will be cleared.
*/
export async function setLabelsForJob(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not positive how this is going to be used, but I do not like endpoints that require you to pass in what you think should exist plus any new info.

I'd want to have an endpoint to add one or more labels without changing any existing labels and an endpoint for removing one or more labels.

Copy link
Contributor Author

@indiejames indiejames Sep 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The AC for this ticket:

* when a user submits a request they can submit one or more labels for the job
* the new label parameter is documented with examples

This ticket just allows the user to set labels when making a request. So not updating things. The updates will happen in later tickets. But one of the major use cases for the other tickets is to allow users to add labels from the workflow-ui, in which case I would think the UI should show them the existing labels, which means you would have them and could resend the whole list. But if you want to do it piecemeal for some reason then that can be a different function.

Copy link
Contributor Author

@indiejames indiejames Sep 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing I have tried to avoid is adding a full model for labels, since they are so simple, but if you want CRUD at the label level then maybe we should make a full model.

Copy link
Contributor

@chris-durbin chris-durbin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested things out successfully in a sandbox environment. I ran into one issue with a 500 error returned (I assume because of the 255 character limit) when passing in a wall of text for the label. I think we have two options:

  1. Reject the request with a 400 error and say each label is limited to 255 characters
  2. Accept the request and truncate the label to 255 characters

@indiejames
Copy link
Contributor Author

I tested things out successfully in a sandbox environment. I ran into one issue with a 500 error returned (I assume because of the 255 character limit) when passing in a wall of text for the label. I think we have two options:

  1. Reject the request with a 400 error and say each label is limited to 255 characters
  2. Accept the request and truncate the label to 255 characters

I vote for option 1. I was already thinking that I should add a line in the docs about the 255 character limit.

`value` varchar(255) not null,
`createdAt` datetime not null,
`updatedAt` datetime not null,
UNIQUE(username, value)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't we make the value itself be the unique key?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the use case of username and value?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we did that then only one person could be associated with the label value. We want to be able to look up the labels for a person so we can populate an autocomplete, so we need to have both value and username here.

Copy link
Member

@ygliuvt ygliuvt Sep 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I log in as an admin, I think I should see all labels rather than just mine. There will be so many duplicate label values in the table and that will make cleanup much harder.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can get the labels for a user through the jobs table and the association with labels.

describe('update labels for job', async function () {
const updatedLabels = ['baz', 'buzz'];
it('updates the labels for the job', async function () {
await setLabelsForJob(this.trx, this.job.jobID, this.job.username, labels);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: We can remove this line if we make the whole test a transaction with three steps and I think the test will be more readable if we do that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like for tests to not rely on other tests setting things up in the database. It makes them too fragile.

if (!labels) return;

// delete any labels that already exist for the job
await transaction('jobs_labels')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about the labels table?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't want to delete those. Labels can be re-used.

Copy link
Contributor

@chris-durbin chris-durbin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verified functionality for rejecting requests with labels greater than 255 along and verified 255 or less continued to work as expected.

@indiejames indiejames merged commit c0250ec into main Sep 27, 2024
4 of 6 checks passed
@indiejames indiejames deleted the harmony-1894 branch September 27, 2024 18:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants