Validate Thing Descriptions during startup
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
Research direction
Start by tracing server startup and the existing ThingDescription and DataSchema generation paths. Determine how startup can generate a Thing Description and how a Python-level opt-out should work, including for test code. Done means invalid deferred type annotations fail during startup with a meaningful traceback, while the check can be disabled.
Written by the indexing model from the issue text.
Description
If a Thing Description can't be generated for a particular Thing, there's not much point starting the server: it would probably be more useful to fail with a meaningful traceback than start up only to fail when a client attempts to use it.
This is particularly important as we support deferred type annotations: the various models and types associated with a Thing (properties, actions, etc.) are not evaluated until they're needed, meaning the server may finish starting up with Things that still have un-evaluated type hints. These may then later fail to be converted to DataSchema instances as needed by the Thing Description.
I think it would be useful to generate a Thing Description during server start-up, to surface these errors early. This isn't an effort-free process and may take a second or two, but I think we'd get more or less all of the benefit from getting to the stage of having at ThingDescription model: we wouldn't actually need to serialise (or validate) the JSON, though we could.
Clearly there would need to be a way to turn this off. I think it shouldn't be that noticeable when starting an HTTP server, but it would be horrible in test code.
I don't know if it would be a good idea to use the config file to specify whether this happens: I think keeping it Python-only would make it easier to skip when needed (in test suites) but benefit from having a sanity check whenever a server starts.
I may also be pessimistic about how long it takes: it could be very quick at which point I'm worrying unduly (though it would still be a good idea to provide an opt-out).
- Dominant language
- Python
- Stars
- 9
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from labthings/labthings-fastapi
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
labthings/labthings-fastapi#405 ·
-
drop-python-version
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
labthings/labthings-fastapi#354 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
labthings/labthings-fastapi#312 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
labthings/labthings-fastapi#404 · 2 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 63/100
labthings/labthings-fastapi#403 · 1 comment ·
All issues in labthings/labthings-fastapi
Similar issues
-
essnmx good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
[Feature] 奇物选择添加优先级 Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
syfoud/Simulated_Scepter#174 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Giskard-AI/giskard-oss#2840 · 1 comment ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Openarea: repo bug perceived difficulty: 2
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
yeti-platform/yeti#1380 ·