Cap uvicorn below 1.0

[eldonm]

Type of Change

• 🐛 Bug Fix
• 🚀 Feature Request
• 🔄 Refactor
• 📖 Documentation Update
• 🔧 Other: dependency constraint

---

Summary

uvicorn was floor-only (>=0.23.0). This caps it below 1.0.

jvspatial is the package that actually drives uvicorn — api/server_run.py:124 calls uvicorn.run(app_path, **uvicorn_config) — so a major release is free to rename or drop the kwargs passed there, and we would find out at a user's startup rather than in CI.

The open range is not theoretical: it let a resolver move an existing environment from uvicorn 0.44 to 0.52 between two installs of the same commit, with nothing in any diff to explain the change. That is what prompted this.

Description

"uvicorn>=0.23.0" → "uvicorn>=0.23.0,<1.0.0", with the rationale in a comment beside it (matching the existing starlette note, which documents why it deliberately has no cap).

Why a range and not ==. An exact pin in a published library propagates conflicts to every downstream that depends on anything else wanting uvicorn — the cure would be worse than the drift. Reproducibility for a given deployment belongs in that deployment's lock/constraints file, where it can be exact without constraining anyone else.

Changes Made

1. pyproject.toml — cap + rationale comment.
2. CHANGELOG.md — [Unreleased] / Changed.

Checklist

• Code follows the project's coding guidelines.
• Tests added — none; this is a metadata constraint with no runtime behavior. Resolution is exercised by every CI install.
• Documentation updated — changelog.
• Existing tests pass locally — tests/api/test_server_config.py + tests/api/test_server_env_integration.py green; pre-commit clean.
• Any dependencies introduced are justified — none introduced; one constrained.

Steps to Test

pip install -e .
python -c "import uvicorn; print(uvicorn.__version__)"   # < 1.0

Questions or Concerns

If you would rather track uvicorn majors aggressively than cap them, the alternative is leaving it open and adding a scheduled CI job that installs with --upgrade and runs the suite, so a breaking major surfaces as a failed job instead of a failed user startup. Happy to do that instead — the goal is that the version moves visibly, not that it never moves.

Companion note: jvagent has no uvicorn dependency of its own to cap — it never imports it, and inherits this one transitively — so this is the only place the constraint belongs.

[github-actions]

Benchmark comparison

Threshold: ±25% (informational, does not block merge)

benchmark	baseline (s)	current (s)	delta	status
tests/benchmarks/test_deferred_save_benchmarks.py::test_bench_deferred_save_batched_100	0.041134	0.037257	-9.4%	OK
tests/benchmarks/test_deferred_save_benchmarks.py::test_bench_immediate_save_100	0.040949	0.038368	-6.3%	OK
tests/benchmarks/test_jsondb_benchmarks.py::test_bench_jsondb_batched_saves_500	0.419630	0.394167	-6.1%	OK
tests/benchmarks/test_jsondb_benchmarks.py::test_bench_jsondb_count_empty_query	0.872007	0.809665	-7.1%	OK
tests/benchmarks/test_jsondb_benchmarks.py::test_bench_jsondb_count_filtered	1.086054	0.986508	-9.2%	OK
tests/benchmarks/test_jsondb_benchmarks.py::test_bench_jsondb_find_filtered	0.820635	0.740774	-9.7%	OK
tests/benchmarks/test_jsondb_benchmarks.py::test_bench_jsondb_save_throughput	0.001519	0.001417	-6.7%	OK
tests/benchmarks/test_sqlite_benchmarks.py::test_bench_sqlite_count_empty	0.250021	0.240357	-3.9%	OK
tests/benchmarks/test_sqlite_benchmarks.py::test_bench_sqlite_count_fallback_via_regex	0.321091	0.281055	-12.5%	OK
tests/benchmarks/test_sqlite_benchmarks.py::test_bench_sqlite_count_pushdown	0.253636	0.258442	+1.9%	OK
tests/benchmarks/test_sqlite_benchmarks.py::test_bench_sqlite_find_fallback_via_regex	0.280772	0.274536	-2.2%	OK
tests/benchmarks/test_sqlite_benchmarks.py::test_bench_sqlite_find_pushdown	0.246518	0.238251	-3.4%	OK
tests/benchmarks/test_sqlite_benchmarks.py::test_bench_sqlite_sort_limit_pushdown	0.307838	0.272663	-11.4%	OK