Allow "fleet_name" to be either string or string array in "task_request"#64
Allow "fleet_name" to be either string or string array in "task_request"#64lttey wants to merge 2 commits into
Conversation
lttey
changed the title
lttey
changed the title
2. Reject array in fleet_name for robot specific tasks Signed-off-by: lttey <leong_teck_tey@cgh.com.sg>
4421818 to
e54de22
Compare
| "description": "A robot task request always targets exactly one robot, so its nested fleet_name (if given) must be a single string, not an array.", | ||
| "allOf": [ | ||
| { "$ref": "task_request.json" }, | ||
| { "properties": { "fleet_name": { "type": "string" } } } |
There was a problem hiding this comment.
Is the purpose here to prevent fleet_name from being an array when the request is included as part of a robot_task_request? If so, I'm not sure what the point would be...
- Just because
fleet_namehas a single string value doesn't mean that string value matches thefleetstring in thisrobot_task_request. - An array for
fleet_namecould include thefleetstring in thisrobot_task_request, making it a perfectly valid request. - If we were to put additional constraints on
fleet_nameforrobot_task_requestit should probably be that there is nofleet_nameinside therequest.
In short, I don't think adding this constraint does anything to improve the correctness of the schema. I would recommend just reverting the schema here and in estimate_robot_task_request.json to its original form, and leave it to the user to ensure that their fleet and fleet_name values are compatible with each other.
Let me know if there's some other rationale for this change that I'm not thinking of.
There was a problem hiding this comment.
Thanks @mxgrey for your correction. That constraint shouldn't be imposed. Have pushed a commit to undo it.
…om previous commit
2 participants
as refer to feature request
This PR is about to enable task dispatch to subset of fleets.
In scenario where -F -R is specified for task request, fleet_name shall be a string instead of array.