I have a python block in a workflow that’s been working great but suddenly started to fail with this error: [info] [runtime] Python 3.10
[info] Traceback (most recent call last):
[info] File "/tmp/main.py", line 2, in <module>
[info] import msgspec
[info] ModuleNotFoundError: No module named 'msgspec'
[error] (node:1) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
[error] (Use `node --trace-deprecation ...` to show where the warning was created)
Summary
A Python block in a Retool Workflow (Cloud-hosted) that had been working reliably suddenly began failing at runtime with 'ModuleNotFoundError: No module named msgspec' under the Python 3.10 runtime.
AI Response
This matches a recurring pattern where a previously-working Workflow block abruptly fails to resolve a module after a runtime/environment change, even though nothing in the block was edited. A common characteristic is that the block still runs when executed in the editor with previous blocks, but fails on a full or scheduled run because those execute in a different environment. Reported workarounds include explicitly re-declaring/adding the dependency in the Workflow's Python library settings (and pinning a known-good version), then re-saving and re-deploying so the runtime rebuilds with the module present. Confirming whether the failure only occurs on the full/scheduled run versus single-block execution will help isolate it.
Sources
Previously scheduled Workflow fails: Error cannot find module numbro
A solved report corroborating the same pattern—a previously-working scheduled Workflow suddenly failing with a module-not-found error that works when run block-by-block but fails on full/scheduled runs—along with a workaround and staff acknowledgment.
Workflows: python package is installed but import fails
A solved, bug-tagged topic specifically about a Python package failing to import inside a Workflow Python block despite being available, closely mirroring this module-resolution failure.
The Community Team is testing out a new automation. Let us know if it's helpful (or not) by leaving a 
, 
, or 
. Or by marking this post as the "Solution"! Let us know if you have any feedback here. 
I can see that msgspec exists in the Python 3.14 package, but I’m using a glmnet library that isn’t available for 3.14 yet. It seems to be an issue with 3.10 missing the msgspec module at startup
This is the per-image package thing. Retool pre-installs a different package set for each Python version image, so msgspec is baked into the 3.14 image but not the 3.10 one. Add msgspec under the workflow's Python libraries in settings, it pip installs it at runtime. Re-save and re-deploy and the 3.10 block should pick it up.
Hi Bill, thanks for the details here! Sorry this one's been a headache, especially since the block was working fine before.
I tried to reproduce this on Python 3.10, and msgspec is actually included in the default 3.10 environment on my end. I believe the Workflows Python runner relies on it under the hood, which is why the traceback points at /tmp/main.py rather than your own code. So I don't think it's simply missing from the 3.10 image. My hunch is it has to do with the environment that gets built when a workflow includes extra libraries like python-glmnet.
To help narrow it down, could you share:
- Whether it fails on every run or only some of the time (for example, scheduled runs vs. running the block in the editor)
- The full list of libraries in the workflow's Python library settings, with versions
- Whether anything changed (or you got a different error) if you tried adding
msgspec there as Rachel suggested
- Roughly when you last saw the error (date, time, and timezone)
Once I have that I'll keep digging and update this thread. Let me know if anything changes in the meantime!
What’s strange is that it’s intermittent. It will randomly start working and then quit again. So I preloaded msgspec in the library using the modify requirements txt and that seems to work consistently now.