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

feat(shared-data): json protocol schema 8 #13848

Merged
merged 23 commits into from
Oct 31, 2023
Merged

feat(shared-data): json protocol schema 8 #13848

merged 23 commits into from
Oct 31, 2023

Conversation

sfoster1
Copy link
Member

@sfoster1 sfoster1 commented Oct 25, 2023

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 the commands array have to match that. You specify a liquidSchemaId and the elements of the liquid 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

  • odd can render protocols tagged jp8
  • app can render protocols tagged jp8
  • offline analysis can handle protocols tagged jp8
  • robot analysis can handle protocols tagged jp8
  • robot can execute protocols tagged jp8
  • if you have a jp8 protocol run, analysis, and protocol saved on the robot and then you downgrade, the server is still operational

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.
@sfoster1 sfoster1 requested a review from a team as a code owner October 25, 2023 19:34
@sfoster1 sfoster1 requested a review from a team October 25, 2023 19:34
@sfoster1 sfoster1 requested a review from a team as a code owner October 25, 2023 19:34
@sfoster1 sfoster1 marked this pull request as draft October 25, 2023 19:34
Copy link
Contributor

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
Copy link

codecov bot commented Oct 25, 2023

Codecov Report

Merging #13848 (eeb8e4b) into edge (6b79819) will increase coverage by 0.14%.
Report is 18 commits behind head on edge.
The diff coverage is 84.39%.

❗ Current head eeb8e4b differs from pull request most recent head 4509338. Consider uploading reports for the commit 4509338 to get more accurate results

Additional details and impacted files

Impacted file tree graph

@@            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     
Flag Coverage Δ
app 43.57% <ø> (-24.57%) ⬇️
g-code-testing 96.44% <ø> (ø)
notify-server 89.13% <ø> (ø)
protocol-designer 45.45% <ø> (ø)
shared-data 72.96% <84.39%> (+0.74%) ⬆️
step-generation 84.95% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
api/src/opentrons/protocol_reader/role_analyzer.py 100.00% <ø> (ø)
.../src/opentrons/protocol_runner/json_file_reader.py 100.00% <ø> (ø)
shared-data/js/helpers/parseProtocolData.ts 63.15% <ø> (ø)
...ata/python/opentrons_shared_data/deck/dev_types.py 100.00% <100.00%> (ø)
...-data/python/opentrons_shared_data/errors/codes.py 93.33% <100.00%> (+0.09%) ⬆️
.../opentrons_shared_data/protocol/models/__init__.py 100.00% <100.00%> (ø)
..._shared_data/protocol/models/protocol_schema_v8.py 100.00% <100.00%> (ø)
.../python/opentrons_shared_data/errors/exceptions.py 60.51% <66.66%> (+0.08%) ⬆️
...a/python/opentrons_shared_data/command/__init__.py 0.00% <0.00%> (ø)
shared-data/js/protocols.ts 81.65% <81.65%> (ø)

... and 868 files with indirect coverage changes

@jbleon95
Copy link
Contributor

jbleon95 commented Oct 27, 2023

As discussed in the comments on #13854, we should add some sort of deckVersion field along with deckId to allow robot server/protocol runner to know whether to load fixed trash or not, rather than just relying on schema version moving forward.

Comment on lines 151 to 160
"commandAnnotationSchemaId": {
"description": "The schema to which the command annotations adhere.",
"type": "string"
},

"commandAnnotations": {
"type": "array",
"items": { "$ref": "#/properties/commandAnnotationSchemaRef" }
}
}
Copy link
Collaborator

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?

Copy link
Member Author

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

@sfoster1 sfoster1 marked this pull request as ready for review October 30, 2023 13:37
@sfoster1 sfoster1 requested review from a team as code owners October 30, 2023 13:37
@sfoster1 sfoster1 requested review from ncdiehl11 and removed request for a team October 30, 2023 13:37
@sfoster1 sfoster1 requested a review from a team as a code owner October 30, 2023 14:00
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
Copy link
Collaborator

@jerader jerader left a 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
Copy link
Collaborator

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'
Copy link
Collaborator

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(
Copy link
Collaborator

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.

Copy link
Member Author

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.

Copy link
Contributor

@SyntaxColoring SyntaxColoring left a 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!

Comment on lines +208 to +211
},
"4006": {
"detail": "Invalid Protocol Data",
"category": "generalError"
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice, thank you.

Copy link
Contributor

@b-cooper b-cooper left a comment

Choose a reason for hiding this comment

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

🏈

@sfoster1 sfoster1 merged commit 196fdc0 into edge Oct 31, 2023
25 of 26 checks passed
@sfoster1 sfoster1 deleted the add-json-protocol-8 branch October 31, 2023 15:19
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.

5 participants