Harmony 1996: Add 'empty-result' status to WorkItem class and work-items table #683
Conversation
and level/category to job_errors to support warnings as well as errors
db/db.sql
Outdated
| @@ -80,7 +92,8 @@ CREATE TABLE `work_items` ( | |||
| `workflowStepIndex` integer not null, | |||
| `scrollID` varchar(4096), | |||
| `serviceID` varchar(255) not null, | |||
| `status` text check (`status` in ('ready', 'queued', 'running', 'successful', 'failed', 'canceled')) not null, | |||
| `status` varchar(255) check (`status` in ('ready', 'queued', 'running', 'successful', 'failed', 'canceled', 'warning')) not null, | |||
| `subStatus` varchar(255) check (`subStatus` in ('no-data')), | |||
There was a problem hiding this comment.
The column name should besub_status to match the Postgres definition.
db/db.sql
Outdated
| CREATE INDEX work_items_jobID_idx ON work_items(jobID); | ||
| CREATE INDEX work_items_serviceID_idx ON work_items(serviceID); | ||
| CREATE INDEX work_items_status_idx ON work_items(status); | ||
| CREATE INDEX work_items_subStatus_idx ON work_items(subStatus); |
There was a problem hiding this comment.
The column name should besub_status to match the Postgres definition.
db/db.sql
Outdated
| ) | ||
| ) not null default 'error', | ||
| `category` varchar(255) check ( | ||
| `category` in ( |
There was a problem hiding this comment.
Do we want to have to change this check every time a new category is added in service lib? If we're adding new categories only via pull request in the service lib, it has been validated already by the time it gets to Harmony. This is also missing the existing error categories like "Server", "Forbidden".
There was a problem hiding this comment.
That's a good point. I'll drop this constraint here as well as in the migration.
| @@ -51,6 +51,9 @@ export default class WorkItem extends Record implements WorkItemRecord { | |||
| // The status of the operation - see WorkItemStatus | |||
| status?: WorkItemStatus; | |||
|
|
|||
| // The sub-status of the operation - see WorkItemSubStatus | |||
| subStatus?: WorkItemSubStatus; | |||
There was a problem hiding this comment.
nit: I think we have coding standard to use underscores in new column names. i.e. sub_status.
I commented above that the sub_status name is not consistent in db definition vs migration. If you want to go with subStatus, it is fine with me as long as we make it consistent.
There was a problem hiding this comment.
For some reason I thought it could be snake case in the dB, but camel case in the models. I see now that we are not doing that (maybe it doesn't work). I'll make it snake case here.
| exports.up = function (knex, Promise) { | ||
| return knex.schema.raw(` | ||
| ALTER TABLE "work_items" | ||
| DROP CONSTRAINT "work_items_status_check", |
There was a problem hiding this comment.
Why do you need to drop work_items_status_check before adding it?
There was a problem hiding this comment.
Same question for the "down" migration.
There was a problem hiding this comment.
because there is already a constraint with that name. We can't update it, we have to drop it then add it.
sub_status field to be consistent
Jira Issue ID
HARMONY-1996
Description
This PR adds a new status to WorkItem to represent when a service processed the work-item, but produced to data. This is to allow us to provide a better experience for users by not staging empty files.
Local Test Steps
PR Acceptance Checklist
Documentation updated (if needed)