docassemble 1.9.7 fails to start after installing openai package (pydantic-core mismatch)

[jscarruth]

I encountered a startup failure in docassemble 1.9.7 after installing the openai Python package through Package Management.
The issue results in a complete application failure with HTTP 500 errors and uWSGI unable to load the Python app.

Environment:- docassemble version: 1.9.7

• Docker image: jhpyle/docassemble:1.9.7
• Platform: Docker Desktop (Mac, Apple Silicon)

Steps to reproduce:

1. Start a fresh docassemble 1.9.7 instance using Docker
2. Log in as admin
3. Go to Package Management
4. Install: openai
5. Restart the container (docker compose down / up)

Behavior:
Application fails to start. All pages return HTTP 500.
uWSGI logs show "no python application found".

Details:
SystemError: The installed pydantic-core version (2.45.0) is incompatible with the current pydantic version, which requires 2.41.5.

Working combinations:

• docassemble 1.9.6 + openai 1.107.3 → works
• docassemble 1.9.6 + openai 2.30.0 → works

Failing combinations:

• docassemble 1.9.7 + openai 2.30.0 → fails
• docassemble 1.9.7 + openai 1.107.3 → fails

Which suggests a regression or dependency incompatibility introduced in 1.9.7.

[jhpyle]

I think there is something else going on. The uwsgi.log file may have more information about why uWSGI isn't starting. I am able to install openai on servers running 1.9.7 without a problem, using both docassemble-compose and the monolithic Docker image. I don't know what type of Docker Compose setup you are using. I don't know why you would need to docker compose down after installing a package using the web interface. I don't have the ability to test on a Mac; I am running on amd64.

[jscarruth]

I use bind mounts to capture persistent data (in case I need to move/restore docassemble hosts) using docker compose down is the best way to test persistence. The Mac environment emulates the X86 environment via rosetta. For clarity, this was a brand new install (as this is a new computer) 1.9.7 and the current or previous version (that I was using) of the openai module resulted in the system error. When I installed 1.9.6, I tested with both the older and latest version of the openai module and the persistence is maintained after a docker compose down command.

here is the log file I pulled when the error occurred:

• ** ---------- .> results: redis://localhost/
• *** --- * --- .> concurrency: 1 (prefork)
  -- ******* ---- .> task events: OFF (enable -E to monitor tasks in this worker)
  --- ***** -----
  -------------- [queues]
  .> celery exchange=celery(direct) key=celery

[tasks]
. docassemble.webapp.worker_tasks.background_action
. docassemble.webapp.worker_tasks.email_attachments
. docassemble.webapp.worker_tasks.make_png_for_pdf
. docassemble.webapp.worker_tasks.ocr_dummy
. docassemble.webapp.worker_tasks.ocr_finalize
. docassemble.webapp.worker_tasks.ocr_google
. docassemble.webapp.worker_tasks.ocr_page
. docassemble.webapp.worker_tasks.reset_server
. docassemble.webapp.worker_tasks.sync_with_google_drive
. docassemble.webapp.worker_tasks.sync_with_onedrive
. docassemble.webapp.worker_tasks.update_packages

[2026-04-08 10:23:07,864: ERROR/MainProcess] consumer: Cannot connect to amqp://guest:**@ac376ddf3556:5672//: [Errno 111] Connection refused.
Trying again in 2.00 seconds... (1/100)

[2026-04-08 10:23:09,870: INFO/MainProcess] Connected to amqp://guest:**@ac376ddf3556:5672//
[2026-04-08 10:23:09,871: INFO/MainProcess] mingle: searching for neighbors
[2026-04-08 10:23:10,889: INFO/MainProcess] mingle: all alone
[2026-04-08 10:23:10,907: INFO/MainProcess] celery@ac376ddf3556 ready.

worker: Warm shutdown (MainProcess)

-------------- celery@c960db359a50 v5.6.0 (recovery)
--- ***** -----
-- ******* ---- Linux-6.12.76-linuxkit-aarch64-with-glibc2.39 2026-04-08 10:26:10

• *** --- * ---
• ** ---------- [config]
• ** ---------- .> app: docassemble.webapp.worker:0xffff937387d0
• ** ---------- .> transport: amqp://guest:**@c960db359a50:5672//
• ** ---------- .> results: redis://localhost/
• *** --- * --- .> concurrency: 1 (prefork)
  -- ******* ---- .> task events: OFF (enable -E to monitor tasks in this worker)
  --- ***** -----
  -------------- [queues]
  .> celery exchange=celery(direct) key=celery

[tasks]
. docassemble.webapp.worker_tasks.background_action
. docassemble.webapp.worker_tasks.email_attachments
. docassemble.webapp.worker_tasks.make_png_for_pdf
. docassemble.webapp.worker_tasks.ocr_dummy
. docassemble.webapp.worker_tasks.ocr_finalize
. docassemble.webapp.worker_tasks.ocr_google
. docassemble.webapp.worker_tasks.ocr_page
. docassemble.webapp.worker_tasks.reset_server
. docassemble.webapp.worker_tasks.sync_with_google_drive
. docassemble.webapp.worker_tasks.sync_with_onedrive
. docassemble.webapp.worker_tasks.update_packages

[2026-04-08 10:26:10,302: INFO/MainProcess] Connected to amqp://guest:**@c960db359a50:5672//
[2026-04-08 10:26:10,303: INFO/MainProcess] mingle: searching for neighbors
[2026-04-08 10:26:11,318: INFO/MainProcess] mingle: all alone
[2026-04-08 10:26:11,338: INFO/MainProcess] celery@c960db359a50 ready.
[2026-04-08 10:26:15,877: INFO/MainProcess] sync with worker1@c960db359a50

worker: Warm shutdown (MainProcess)

-------------- celery@3df825e3750d v5.6.0 (recovery)
--- ***** -----
-- ******* ---- Linux-6.12.76-linuxkit-aarch64-with-glibc2.39 2026-04-08 10:32:33

• *** --- * ---
• ** ---------- [config]
• ** ---------- .> app: docassemble.webapp.worker:0xffffaf878800
• ** ---------- .> transport: amqp://guest:**@3df825e3750d:5672//
• ** ---------- .> results: redis://localhost/
• *** --- * --- .> concurrency: 1 (prefork)
  -- ******* ---- .> task events: OFF (enable -E to monitor tasks in this worker)
  --- ***** -----
  -------------- [queues]
  .> celery exchange=celery(direct) key=celery

[tasks]
. docassemble.webapp.worker_tasks.background_action
. docassemble.webapp.worker_tasks.email_attachments
. docassemble.webapp.worker_tasks.make_png_for_pdf
. docassemble.webapp.worker_tasks.ocr_dummy
. docassemble.webapp.worker_tasks.ocr_finalize
. docassemble.webapp.worker_tasks.ocr_google
. docassemble.webapp.worker_tasks.ocr_page
. docassemble.webapp.worker_tasks.reset_server
. docassemble.webapp.worker_tasks.sync_with_google_drive
. docassemble.webapp.worker_tasks.sync_with_onedrive
. docassemble.webapp.worker_tasks.update_packages

[2026-04-08 10:32:33,898: INFO/MainProcess] Connected to amqp://guest:**@3df825e3750d:5672//
[2026-04-08 10:32:33,901: INFO/MainProcess] mingle: searching for neighbors
[2026-04-08 10:32:34,911: INFO/MainProcess] mingle: all alone
[2026-04-08 10:32:34,930: INFO/MainProcess] celery@3df825e3750d ready.
[2026-04-08 10:32:39,470: INFO/MainProcess] sync with worker1@3df825e3750d

What's next:
Try Docker Debug for seamless, persistent debugging tools in any container or image → docker debug docassemble
Learn more at https://docs.docker.com/go/debug-cli/

What's next:
Try Docker Debug for seamless, persistent debugging tools in any container or image → docker debug docassemble
Learn more at https://docs.docker.com/go/debug-cli/
localhost [pid: 908|app: -1|req: -1/11] 192.168.65.1 () {54 vars in 976 bytes} [Wed Apr 8 10:27:59 2026] GET /health_check?ready=1 => generated 21 bytes in 0 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 3)
--- no python application found, check your startup logs for errors ---
localhost [pid: 908|app: -1|req: -1/12] 192.168.65.1 () {54 vars in 976 bytes} [Wed Apr 8 10:28:09 2026] GET /health_check?ready=1 => generated 21 bytes in 0 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 4)
--- no python application found, check your startup logs for errors ---
localhost [pid: 908|app: -1|req: -1/13] 192.168.65.1 () {54 vars in 976 bytes} [Wed Apr 8 10:28:19 2026] GET /health_check?ready=1 => generated 21 bytes in 0 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 0)
--- no python application found, check your startup logs for errors ---
localhost [pid: 908|app: -1|req: -1/14] 192.168.65.1 () {54 vars in 987 bytes} [Wed Apr 8 10:28:23 2026] GET /user/sign-in?from_logout=1 => generated 21 bytes in 0 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 1)
--- no python application found, check your startup logs for errors ---
localhost [pid: 908|app: -1|req: -1/15] 192.168.65.1 () {54 vars in 987 bytes} [Wed Apr 8 10:28:28 2026] GET /user/sign-in?from_logout=1 => generated 21 bytes in 0 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 2)
--- no python application found, check your startup logs for errors ---
localhost [pid: 908|app: -1|req: -1/16] 192.168.65.1 () {54 vars in 987 bytes} [Wed Apr 8 10:30:26 2026] GET /user/sign-in?from_logout=1 => generated 21 bytes in 0 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 5)
--- no python application found, check your startup logs for errors ---
localhost [pid: 908|app: -1|req: -1/17] 192.168.65.1 () {54 vars in 987 bytes} [Wed Apr 8 10:30:52 2026] GET /user/sign-in?from_logout=1 => generated 21 bytes in 0 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 3)
--- no python application found, check your startup logs for errors ---
localhost [pid: 908|app: -1|req: -1/18] 192.168.65.1 () {54 vars in 987 bytes} [Wed Apr 8 10:30:53 2026] GET /user/sign-in?from_logout=1 => generated 21 bytes in 0 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 4)
--- no python application found, check your startup logs for errors ---
localhost [pid: 908|app: -1|req: -1/19] 192.168.65.1 () {54 vars in 987 bytes} [Wed Apr 8 10:30:54 2026] GET /user/sign-in?from_logout=1 => generated 21 bytes in 0 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 0)
...brutally killing workers...
Sending stop command
Waiting for uwsgi to stop
SIGINT/SIGTERM received...killing workers...
worker 1 buried after 1 seconds
goodbye to uWSGI.
uwsgi stopped
[uWSGI] getting INI configuration from /usr/share/docassemble/config/docassemble.ini
*** Starting uWSGI 2.0.31 (64bit) on [Wed Apr 8 10:32:45 2026] ***
compiled with version: 13.3.0 on 05 April 2026 20:51:01
os: Linux-6.12.76-linuxkit #1 SMP Sun Mar 8 14:41:59 UTC 2026
nodename: 3df825e3750d
machine: aarch64
clock source: unix
pcre jit disabled
detected number of CPU cores: 4
current working directory: /
writing pidfile to /var/run/uwsgi/uwsgi.pid
detected binary path: /usr/share/docassemble/local3.12/bin/uwsgi
your memory page size is 4096 bytes
detected max file descriptor number: 1048576
VirtualHosting mode enabled.
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /var/run/uwsgi/docassemble.sock fd 3
Python version: 3.12.3 (main, Mar 3 2026, 12:15:18) [GCC 13.3.0]
PEP 405 virtualenv detected: /usr/share/docassemble/local3.12
Set PythonHome to /usr/share/docassemble/local3.12
Python main interpreter initialized at 0xffff9e53b598
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 594464 bytes (580 KB) for 6 cores
*** Operational MODE: threaded ***
mounting docassemble.webapp.run:application on /
Traceback (most recent call last):
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/docassemble/webapp/run.py", line 1, in
from docassemble.webapp.server import app as application
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/docassemble/webapp/server.py", line 60, in
import docassemble.base.interview_cache
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/docassemble/base/interview_cache.py", line 2, in
import docassemble.base.parse
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/docassemble/base/parse.py", line 53, in
import docassemble.base.util
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/docassemble/base/util.py", line 65, in
import docassemble.base.geocode
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/docassemble/base/geocode.py", line 2, in
from geopy.geocoders import GoogleV3
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/geopy/init.py", line 12, in
from geopy.geocoders import * # noqa
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/geopy/geocoders/init.py", line 224, in
from geopy.geocoders.arcgis import ArcGIS
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/geopy/geocoders/arcgis.py", line 11, in
from geopy.geocoders.base import DEFAULT_SENTINEL, Geocoder, _synchronized
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/geopy/geocoders/base.py", line 7, in
from geopy.adapters import (
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/geopy/adapters.py", line 56, in
import aiohttp
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/aiohttp/init.py", line 6, in
from .client import (
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/aiohttp/client.py", line 38, in
from yarl import URL
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/yarl/init.py", line 2, in
from ._url import URL, cache_clear, cache_configure, cache_info
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/yarl/_url.py", line 59, in
from pydantic import GetCoreSchemaHandler, GetJsonSchemaHandler
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/pydantic/init.py", line 8, in
_ensure_pydantic_core_version()
File "/usr/share/docassemble/local3.12/lib/python3.12/site-packages/pydantic/version.py", line 94, in _ensure_pydantic_core_version
raise SystemError(
SystemError: The installed pydantic-core version (2.45.0) is incompatible with the current pydantic version, which requires 2.41.5. If you encounter this error, make sure that you haven't upgraded pydantic-core manually.
unable to load app 0 (mountpoint='/') (callable not found or import error)
*** no app loaded. going in full dynamic mode ***
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 886)
spawned uWSGI worker 1 (pid: 902, cores: 6)
--- no python application found, check your startup logs for errors ---
localhost [pid: 902|app: -1|req: -1/1] 127.0.0.1 () {34 vars in 370 bytes} [Wed Apr 8 10:32:52 2026] GET / => generated 21 bytes in 0 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 0)
--- no python application found, check your startup logs for errors ---
localhost [pid: 902|app: -1|req: -1/2] 192.168.65.1 () {54 vars in 987 bytes} [Wed Apr 8 10:33:40 2026] GET /user/sign-in?from_logout=1 => generated 21 bytes in 0 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 1)
--- no python application found, check your startup logs for errors ---
localhost [pid: 902|app: -1|req: -1/3] 192.168.65.1 () {54 vars in 987 bytes} [Wed Apr 8 10:44:38 2026] GET /user/sign-in?from_logout=1 => generated 21 bytes in 0 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 2)

What's next:
Try Docker Debug for seamless, persistent debugging tools in any container or image → docker debug docassemble
Learn more at https://docs.docker.com/go/debug-cli/

What's next:
Try Docker Debug for seamless, persistent debugging tools in any container or image → docker debug docassemble
Learn more at https://docs.docker.com/go/debug-cli/

and this is what stuck out to me:
SystemError: The installed pydantic-core version (2.45.0) is incompatible with the current pydantic version, which requires 2.41.5

[jhpyle]

The issue is that yarl (a URL parsing library that is a deep dependency of docassemble) tries to import pydantic and skips the import if there is an ImportError, but if there is another type of error while importing, it raises that error. Importing pydantic is not necessary to the operation of yarl, and yarl has no dependency on pydantic. pydantic will throw a SystemError on import if it doesn't like the version of pydantic-core that is installed.

I am not sure how the versions of pydantic and pydantic-core could get misaligned due to openai being installed. openai depends on pydantic>=1.9.0,<3, and pydantic in turn depends on a particular version of pydantic-core.

Docassemble used to have a pinned dependency on pydantic and pydantic-core, but it doesn't any more. Thus you could have unnecessary versions of pydantic and pydantic-core installed on your system if you upgraded docassemble. If you had the versions docassemble used to require, they would not be out of sync, and pydantic would not raise an error on import. Perhaps there is another package besides openai that is messing up the relative versions of pydantic and pydantic-core, or maybe there is something about the Apple environment that causes them to be misaligned. Apparently pydantic-core requires binaries, so there may be a binary-related issue on arm64 that isn't present on amd64.

In any case, I would recommend that before you install openai, you uninstall both pydantic packages. Then, I would assume, when openai is installed, the correct versions of pydantic and pydantic-core will be installed.

[jscarruth]

I suppose it can be closed - but just want to clarify that this was a fresh install of docassemble (using the latest available -> 1.9.7) and not an upgrade from a previous version.

[jhpyle]

A fresh install could mean 1) a container is created using environment variables or a docker volume linking to existing application data that should be restored, or 2) a container is created without any existing application data associated with it.

Under (1), on startup the stored packages listed on the Package Management page will be installed, including pydantic packages, because they used to be installed. The list of packages on this page is kept in a SQL table, and is part of the application data.

Under (2), pydantic packages would not be installed because they are not dependencies of docassemble version 1.9.7.

I would guess that package mismatch problems might happen differently depending on whether the fresh install was type (1) or type (2).

[jpagh]

I have an Apple M and would be interested in helping to resolve this issue.

@jscarruth

• Have you tested this on the new v1.9.8 image?
• Can you tell me if you were loading previous data or if this was entirely fresh (jhpyle's last question)?
• Can you provide the Docker Compose file and/or any other configuration details that you used so that I can recreate your scenario as exactly as possible?

Unrelated to this issue, but just FYI, your Apple M is using the arm64/aarch64 image, not the x64 imageas you stated, which can be seen in your posted logs: Linux-6.12.76-linuxkit-aarch64-with-glibc2.39.