Skip to content

Better errors for bad return values#333

Draft
rwb27 wants to merge 4 commits intomainfrom
validate-return-values
Draft

Better errors for bad return values#333
rwb27 wants to merge 4 commits intomainfrom
validate-return-values

Conversation

@rwb27
Copy link
Copy Markdown
Collaborator

@rwb27 rwb27 commented May 6, 2026

This moves validation of return values into the invocation thread, so we get useful errors. It also handles serialization errors elsewhere in the server, which ought to cut down on the number of unpleasant stack traces we get in the logs.

This is based on global locking and will need rebasing once that's in.

@rwb27 rwb27 added this to the v0.3.0 milestone May 7, 2026
@rwb27 rwb27 force-pushed the validate-return-values branch from 9c256a9 to e945edc Compare May 7, 2026 08:29
@barecheck
Copy link
Copy Markdown

barecheck Bot commented May 7, 2026

Barecheck - Code coverage report

Total: 96.77%

Your code coverage diff: -0.09% ▾

Uncovered files and lines
FileLines
src/labthings_fastapi/actions.py166, 170, 552-553, 566, 591-592, 779, 971-972, 975, 978, 1026
src/labthings_fastapi/client/__init__.py62, 65-66, 114-115, 258-261, 368, 468
src/labthings_fastapi/server/__init__.py322, 336-339

rwb27 added 4 commits May 7, 2026 12:09
Action outputs are serialized using a pydantic model. We now create (and validate) this model
instance in the action thread, rather than in the response handler returning it to the user.

This means that validation errors will now be caught and logged, and there won't be loads of ASGI/routing/FastAPI stuff in the stack trace.

It does not yet fix the problem of un-JSONable types being returned, because `pydantic` will
allow `Any` to be wrapped in a `RootModel` which validates fine, and fails at serialisation time.
The stack trace is not useful when an action returns an invalid value, as it only tells us about LabThings code. The error is still logged, but there's no stack trace.
This commit:
* Adds an error handler for PydanticSerializationError
* Fixes a race condition in invocation responses that could result in an output being present before the response marks the invocation as complete
* Handles HTTP errors when polling actions in ThingClient
* Ensures that invocation models attach useful debug info to serialization errors (they add the invocation ID and action path).
Depending on whether the action fails before or after the initial response is sent to the client, we
get a different exception (with the same message).

This commit will accept either kind of failure so long as it includes the same message. This should
prevent intermittent test failures: there's nothing to synchronise the action thread and the HTTP
response, and it's not feasible to add that now.
@rwb27 rwb27 force-pushed the validate-return-values branch from e945edc to 1a60cdd Compare May 7, 2026 11:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant