Bug with array payload validation about asynction HOT 6 CLOSED

@dedoussis close away

from asynction.

@dedoussis If I am interpreting things correctly I think that the special case for the array is incorrect and can be removed. Or that some checking needs to be done against the args parameter.

from asynction.

This condition branching is there to account for the case of the handler accepting multiple args. In the case of multiple args, the payload schema is a tuple array. See the payload structure table in the middle of this section of my article: https://www.asyncapi.com/blog/socketio-part2#channels

In the case of a tuple payload, all args need to be validated and not just the first one.
However, I think I have not accounted for the case of the payload being an array rather than a tuple. In the case of an array, we will only need to validate the first arg. Hence we need to have an extra nested condition within if schema_type == "array" to check if there is a prefixItems field or not:

if schema_type == "array":
    if schema.get("prefixItems"):  # tuple
        jsonschema_validate_payload(args, schema)
    else:  # array
        jsonschema_validate_payload(args[0], schema)

from asynction.

@dedoussis I guess what I don't understand is why in the one case where the payload is an array but does not have prefixItems that args would be a tuple containing an array, but in the prefixItems` case that args itself would be the array?

Why would:

type: "array"

Result in ([1,2,3], ) as args

But

type: "array"
prefixItems:
    ...

Result in (1,2,3)

My interpretation of the second case there is that there were multiple payloads rather than an array payload. from everything I've seen (using python-socketio as the client and asynction) the args on a message handler will always only have one item (the payload)

from asynction.

type: "array"
items:
  type: number

The above payload signals that there should only be a single argument of type Sequence[str], ie args == ([1,2,3], ).
Using python-socketio as the client, an event emission of such a payload would look like this:

c.emit("foo-event", data=[1,2,3])

Under the hood, the python-socketio client does some magic to convert non-tuple data to a tuple of a single element, so that [1,2,3] becomes ([1,2,3], ).

And in asynction the handler would look like this:

def on_foo_event(nums: Sequence[int]) -> None:
    ...

Whereas:

type: "array"
prefixItems:
- type: string
- type: number

signals that there should be 2 arguments (one of type string and one of type int, ie args == ("bar", 1))

Using python-socketio as the client, an event emission of such a payload would look like this:

c.emit("foo-event", data=("bar", 1))

Here we pass a tuple as data, so python-socketio won't do any magic conversion.

And in asynction the handler would look like this:

def on_foo_event(word: str, num: int) -> None:
    ...

from asynction.

This fix has been released as part of version 0.7.0. @alex-zywicki If you're happy with it, I can close the issue.

from asynction.