Closed il3ven closed 1 year ago
For json-rpc calls the schema has been taken from ethereum-json-rpc-specification. For zora-get-tokenuri I have created the schema by looking at the response and tested it against the existing data of music-os-accumulator.
I wonder if we should put all of these separate in a sem versioned repository
This PR validates schema for call-block-logs, zora-call-tokenuri, zora-call-tokenmetadatauri, and zora-get-tokenuri. If a
schema
property is provided in message then theresult
is validated against the providedschema
. In case the schema isn't valid the message gets logged and ignored by the lifecycle.For json-rpc calls the schema has been taken from ethereum-json-rpc-specification. For zora-get-tokenuri I have created the schema by looking at the response and tested it against the existing data of music-os-accumulator.
The schema for zora-get-tokenuri is not strict i.e. it can have new fields not mentioned in the schema and there won't be an error. The schema mainly checks if a property is present then it should be of correct type. For example,
body.artwork.info
is not required but if it is present then it should contain auri
field with a valid URI.I wanted to test schemas in the wild before adding them to all the strategies. Hence, this PR excludes sound.
Note to self:
schema
property to message neume-network/schema