All message payload and ack argument schemata should be tuples

[dedoussis]

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):

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:

Table referenced from https://dedouss.is/posts/2021-07-14-documenting-socketio-part-2.html#channels

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]

This issue stemmed from #196