-
Notifications
You must be signed in to change notification settings - Fork 40
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
Custom task type support, refactor tasks to be singular, cleaned up #903
Conversation
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## deploy/hammer #903 +/- ##
==================================================
- Coverage 49.35% 26.91% -22.45%
==================================================
Files 285 157 -128
Lines 7564 5273 -2291
Branches 1050 1353 +303
==================================================
- Hits 3733 1419 -2314
+ Misses 3682 3655 -27
- Partials 149 199 +50
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
updateTasks(); | ||
}; | ||
|
||
const handleCustomTaskDescriptionChange = (newDesc: CustomTaskDescription) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is appears to be a more stripped down version of legacyHandleTaskDescriptionChange
as well. Also is it intended that this does not update the favorite task buffer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also is it intended that this does not update the favorite task buffer?
Yeah, I wasn't planning to support saving custom tasks as favorite tasks.
Since I'm re-visiting the task description changes, I'll see if saving it as a favorite task can be supported easily.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To support favorite tasks for this custom compose, I'd probably like to properly define the model types, so I added a fixme for later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Favorite task is probably the most useful with custom tasks, I think we should support it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but probably not at the moment. We will keep it in view until we finish the more critical items towards ongoing projects and release. For this PR, the cleanup to using single requests is required for the next few features
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
…ting custom tasks Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
…s be compose, display description for short description Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
console.error(JSON.stringify(taskRequest.description)); | ||
return JSON.stringify(taskRequest.description); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
trying to JSON.stringify
might throw an error. You probably want to either return undefined
or let the error propagate up or return a fallback value.
On another note, this piece of code looks very specific, it makes a lot of assumption about the task without checking if it is correct. It should
- Check the category first before attempting to destructure the data.
- Check if the phases has the expected data (does each phase have a category?)
- Check if the activities has the correct data.
- Handle any error from the above checks.
iirc taskRequest.description.category
is not strictly defined in rmf, it is making assumptions on the deployment as well. So this part needs a FIXME
, i.e. the data need to come from rmf.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
trying to JSON.stringify might throw an error. You probably want to either return undefined or let the error propagate up or return a fallback value.
thanks for catching that, will handle that exception.
On another note, this piece of code looks very specific
Yup, generally every single line of code that is task request related is hand-crafted based on know-how at this point, until we move towards validating with schemas we get from RMF.
The schemas are well defined and have not needed much changes so far (thankfully), so all this is a stopgap until the schemas solution rolls in, to get things working on our various projects.
I will add the FIXMEs where needed, but this should not hinder getting features that are urgent in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const deliveryDropoff: DropoffActivity = { | ||
category: 'perform_action', | ||
description: { | ||
unix_millis_action_duration_estimate: 60000, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a blocker since it's the same as the previous code, but shouldn't this be set by rmf?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it's meant to be set by the user, estimating how long each perform action is supposed to take to help RMF plan. It was set manually here, because it is thankfully an invariant (for picking up or dropping off carts in the current project).
But it was also a feature request that we don't bog down the users with too many inputs to fill in, so this is the estimate we chose to use statically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add another FIXME
to this, this design isn't good as we are making assumptions on the deployment again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I introduce back the demos task requests into this, I will refactor them similarly to https://github.com/open-rmf/rmf-web/pull/893/files#diff-70a086cc44648bbf06fb810e18f59a99cfcf139952b6eda2fe1447b0faf31a7c, where they are easier to maintain, testable and have better separation of concern
…cription assumptions Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
What's new
The pasted component must be a valid json to be submitted, and is only the Description component of the task request, while the task category is
compose
,For example, https://gist.github.com/aaronchongth/992f1de8a36188ed22da0e228358d4ae or https://gist.github.com/mxgrey/b7a8ede7075cf7764e622ce8e2996888
Self-checks