An action with `NDArray` return type doesn't work over HTTP

[julianstirling]

Describe the bug
An action with NDArray return type doesn't work over HTTP. It throws a the following error

pydantic_core._pydantic_core.PydanticSerializationError: Unable to serialize unknown type: <class 'numpy.ndarray'>

ArrayModel can be used, but then it is typehinted incorrectly when called on the server

To Reproduce
See unit test added in #230

Expected behaviour
It serialises just as ArrayModel would.

System:

• OS: Kubuntu 24.04
• Python version. 3.11
• Version. 0.0.13

[rwb27]

That's perplexing. I feel like I would have manually checked this worked when I implemented NDArray, but it's so long ago I have no memory of it, and there were precious few tests at that point. I agree this needs fixing soon, because ArrayModel is not a correct type hint.

It is possible (I've not checked) that Annotated[np.ndarray, ArrayModel] would both work and be valid. However, I appreciate that is super ugly.

[julianstirling]

If you look at #232, I had to do something quite manual. I tried even just adding in the annotation directly and it still failed.

I could verify the annotation was there, but it would still not exist after one of the built in FastAPI type functions that passed it into pydantic. The #232 solution would be one way to partially implement #200, it doesn't change how the array is send, but does mean that an np.ndarray typehint should work. And that in a client it is turned back into an Numpy array.

[rwb27]

I have done a little digging, and I think I've figured out where the problem is. When we poll the invocation to get its return value, we use an endpoint that's created by the ActionManager, something like /invocations/{id}. This is type hinted (and has a return model) as InvocationModel. This is an alias of GenericInvocationModel[Any,Any] so the input and output fields are typed as Any. That seems reasonable, except it causes the wrong thing to happen...

The invocation actually returns a more specific GenericInvocationModel[MyInputModel, MyOutputModel] which would serialize correctly, but my guess is that FastAPI is using the model specified in the return type, rather than the object that's actually returned. So I think what happens is:

• The Invocation returns an InvocationModel instance of the specific type (i.e. a subscripted GenericInvocationModel). If we call model_dump_json() on this, it would work.
• This model is the return value of the endpoint function that's called when we poll the invocation.
• FastAPI serialises using the annotated type, which is InvocationModel[Any,Any]:
  • it constructs a generic InvocationModel from the supplied InvocationModel[CorrectInputType, CorrectOutputType], discarding all the type annotations
  • it attempts to serialise this, but has forgotten how to serialise the array, because it no longer has the right type in the model's fields.

It's possible that if I'd used subclassing rather than generics, this would not be a problem, because FastAPI might not reconstruct the model (I've not checked). I suspect I was trying to minimise dynamically-generated classes: normally that's a good decision, but here it may have been the wrong one.

The good news is that there is a very simple solution. When we construct the output model for an action, we use the same code that's already used for properties, which wraps plain types in a RootModel. It ends up doing something quite similar to your solution in #232, but it's a one-liner.

Fix is in #239.

This doesn't solve the issue of making ThingClient return the right type, but I think that is one that merits slightly deeper consideration. As you say, shouldn't make perfect the enemy of done, but ThingClient needs fixing in a number of ways in the near future.