The Socket.IO protocol allows events to have accompanying data that consist of one or multiple arguments. Up until now, Asynction used the following logic in order to validate such event data (either message payloads, or ack callback arguments):
if the JSONSchema of the respective entity (message or ack callback) is a JSONSchema tuple, then treat the entity instance as a sequence of multiple arguments
Else, treat the instance as a single argument.
The above validation logic required asynction to parse the JSONSchema of the respective entity, in order to understand whether it is a tuple schema (contains prefixItems) or not. This however does not play well in more complex schematas that make use of a generic top level JSONSchema keys, such as (oneOf, anyOf, and multipleOf ). In such cases there is no top level prefixItems key and asynction fails to label a schema as a tuple.
Solution
In order to solve the above problem, we need to find a way for the spec or the JSON schema to signal the multiple arguments semantic.
One option would be for Asynction to do a more sophisticated parsing of the schemata object, to detect generic structures that include tuples. However, there is a risk that this more sophisticated parsing would end up being too complex and could turn Asynction into yet another jsonschema parser.
The root cause of this problem is that we treat single argument events and multi-argument events as 2 separate cases:
However, these 2 cases can be reduced to 1. In essence, expressing the single argument using type: object is syntactic sugar for expressing it as a tuple of 1 element:
type: array
prefixItems:
- type: object
If Asynction enforces its users to always use tuples when expressing such JSON schemata (even the single argument ones), then there is no need to parse the schemata themselves.
dedoussis
commented
2 years ago
Problem statement
The Socket.IO protocol allows events to have accompanying data that consist of one or multiple arguments. Up until now, Asynction used the following logic in order to validate such event data (either message payloads, or ack callback arguments):
The above validation logic required asynction to parse the JSONSchema of the respective entity, in order to understand whether it is a tuple schema (contains
prefixItems) or not. This however does not play well in more complex schematas that make use of a generic top level JSONSchema keys, such as (oneOf,anyOf, andmultipleOf). In such cases there is no top levelprefixItemskey and asynction fails to label a schema as a tuple.Solution
In order to solve the above problem, we need to find a way for the spec or the JSON schema to signal the multiple arguments semantic.
One option would be for Asynction to do a more sophisticated parsing of the schemata object, to detect generic structures that include tuples. However, there is a risk that this more sophisticated parsing would end up being too complex and could turn Asynction into yet another
jsonschemaparser.The root cause of this problem is that we treat single argument events and multi-argument events as 2 separate cases:
However, these 2 cases can be reduced to 1. In essence, expressing the single argument using
type: objectis syntactic sugar for expressing it as a tuple of 1 element:If Asynction enforces its users to always use tuples when expressing such JSON schemata (even the single argument ones), then there is no need to parse the schemata themselves.