-
Notifications
You must be signed in to change notification settings - Fork 178
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
feat(shared-data): json protocol schema 8 #13848
Conversation
Add JSON protocol schema 8, which is similar in semantic concept to json protocol schema 7 but - Requires user specification of the schema for the command List This allows json protocols to switch which commands they're interning without requiring further bumps to the protocol schema - Does the same thing for command annotations, liquids, and labware For the same reasons. This should be a big step forward in flexibility for our protocol schemas.
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.
This directory should be camelCase like the reference in the v8 schema commandAnnotation/schemas
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## edge #13848 +/- ##
==========================================
+ Coverage 70.65% 70.79% +0.14%
==========================================
Files 2491 1625 -866
Lines 70040 54034 -16006
Branches 8523 3779 -4744
==========================================
- Hits 49486 38254 -11232
+ Misses 18531 15120 -3411
+ Partials 2023 660 -1363
Flags with carried forward coverage won't be shown. Click here to find out more.
|
As discussed in the comments on #13854, we should add some sort of |
shared-data/protocol/schemas/8.json
Outdated
"commandAnnotationSchemaId": { | ||
"description": "The schema to which the command annotations adhere.", | ||
"type": "string" | ||
}, | ||
|
||
"commandAnnotations": { | ||
"type": "array", | ||
"items": { "$ref": "#/properties/commandAnnotationSchemaRef" } | ||
} | ||
} |
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.
what is an example of commandAnnotations
?
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.
Something like grouping commands into the higher-level (i.e. PD, or python api call) command that created them, for instance. Or into user-specified arbitrary groups. Or time estimates, or really anything
If you are running a dev server, tavern will use that for its tests and print out that it did so. You can also specify host and port for dev server now.
Jsonschema is a lot of things but one thing it isn't is a definer of schema behavior based on values in the document. That's the key to all of this - the document specifying a subschema for part of its content - so we're just going to do it in code instead. That means - In the protocol schema, dynamically subschema'd objects get typed as objects - We get a new typescript validator to handle it all - Also update python for this but it matters a bit less because the python defines what is acceptable anyway, so there's no point trying to be future proof here when downstream consumers will have to change
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.
I reviewed the js stuff and sprinkled in a few clean up suggestions & notes. But lgtm! 🎉
LabwareOffset, | ||
Coordinates, | ||
} from '../../js/types' | ||
// TODO (sb 10/26/22): Separate out calibration commands from protocol schema in RAUT-272 |
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.
I think we can delete this TODO, cc @smb2268
import type * as ProtocolSchemas from '../protocol' | ||
import type { CreateCommand } from '../command/types' | ||
import type { CommandAnnotation } from '../commandAnnotation/types' | ||
import Ajv from 'ajv' |
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.
can we move the Ajv import to be at the top of the imports? And then move the type
imports to be at the bottom of the imports before line 22?
}) | ||
|
||
// note: rejects with an array of ajv errors | ||
export function validate( |
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.
Maybe we can leave a note in here saying this is used in the protocolValidation.test
since other files in the shared-data/js
directory contain utils used outside of tests.
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.
Oh this definitely will be used outside of tests, I just don't want to gate merging this pr on "switching the entire js ecosystem over to json protocol v8". The idea with this function is that you'll use it to validate protocols in js anywhere they appear since it will do the typecasting for you.
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.
Python changes look great. Thank you!
}, | ||
"4006": { | ||
"detail": "Invalid Protocol Data", | ||
"category": "generalError" |
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.
Nice, thank you.
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 JSON protocol schema 8, which is similar in semantic concept to json protocol schema 7 but defines new keys for many large components (commands, annotations, liquids, labware) that set the expected schema for the content for that component.
For instance, now you specify a
commandSchemaId
and the elements of thecommands
array have to match that. You specify aliquidSchemaId
and the elements of theliquid
object have to match that.This hopefully will let us be more flexible with upgrading things like the kinds of commands a protocol can run without having to change the protocol schema itself. Consumers will have to make sure that they can handle the schema for the components, but there's a new provided typescript validator (in
shared-data/js/protocols.ts
) that will validate any version of the protocol we support and return it with appropriate types; that's a bit more spread around in python but it similarly handles everything.Also, you specify the deck schema version now.
This should be integrated into the robot for execution and we should make sure the app doesn't choke on it, but really it's a good way to be able to add new commands without making other protocols accidentally invalid.
This should be a big step forward in flexibility for our protocol schemas.
testing