Fix every pytest warning, and make new ones fail the suite

[JackKelly]

Closes #425.

uv run pytest printed four warnings and, intermittently, two stray SQLAlchemy tracebacks after
the summary line. Three distinct causes, three treatments.

1. Our own bug — fixed the code

define_asset_job deprecates partitions_def ("Partitioning is inferred from the selected assets,
so setting this is redundant"), and defs/schedules.py passed it at both partitioned call sites
(ecmwf_ens_job, live_forecasts_job). Removed, along with the two imports that became unused.

This is a behaviour change dressed as a deprecation fix, so it is asserted rather than assumed.
test_definitions_resolve now checks that each resolved job's partitions_def is the very
object its asset declares:

assert repo.get_job("ecmwf_ens_job").partitions_def is ecmwf_ens_partitions
assert repo.get_job("live_forecasts_job").partitions_def is live_forecast_partitions

A job silently resolving to None, or to a different cadence or start, now fails there rather than
at the next schedule tick. I also diffed the whole resolved repository (every job's partitions_def
plus every schedule's cron, timezone and target job) before and after the change — byte-for-byte
identical, including live_forecasts_job_schedule, which is derived via
build_schedule_from_partitioned_job and so depends on the inference working.

2. Third-party deprecation — narrowly suppressed

Dagster 1.13.16's _core/storage/event_log/sql_event_log.py:3160 calls the
datetime.utcfromtimestamp() that Python 3.12 deprecated. Not fixable from this repo, so it gets a
filterwarnings entry pinned to both the exact message and the exact upstream module:

ignore:datetime\.datetime\.utcfromtimestamp\(\) is deprecated:DeprecationWarning:dagster\._core\.storage\.event_log\.sql_event_log

The module anchor is the whole point — it means the entry can only ever match that one upstream
call and can never mask the same deprecation appearing in our own code. The comment names the
package and version and says to delete it once Dagster moves to timezone-aware datetimes.

3. Teardown noise — root cause found and fixed

Not a warning at all: two Exception during reset or similar tracebacks ending in
sqlite3.ProgrammingError: Cannot operate on a closed database, printed after pytest's summary.

Root cause, and it is ours. DagsterInstance.ephemeral() builds an InMemoryRunStorage and an
InMemoryEventLogStorage. Each opens one SQLAlchemy connection against an in-memory SQLite database
and holds it for the life of the instance (self._held_conn = self._engine.connect()), and each
closes it only in dispose(). DagsterInstance has no finaliser, so an instance handed to the
garbage collector keeps both connections open until interpreter shutdown — where SQLAlchemy's
_finalize_fairy GC path can run after SQLite has already closed the underlying database, and
logs the traceback. Two tracebacks = two held connections = exactly one leaked instance.

All 31 DagsterInstance.ephemeral() call sites were in tests/, and each test created exactly one
instance, so they now take a dagster_instance fixture that enters the instance as a context
manager (__exit__ calls dispose()) and tears it down when the test ends.

Evidence. A throwaway session-end probe counting live in-memory storages whose _held_conn is
still open, run over tests/:

	live in-memory storages	with an open held connection
before	6	6
after	6	0

Same instances still reachable from pytest's own caches either way; the difference is that they are
now disposed. Note the symptom itself is intermittent — it depends on finalisation order at
interpreter shutdown and did not reproduce in ~8 full runs on this machine — which is why the fix is
verified against the leak rather than against the traceback.

filterwarnings = ["error"] — enabled

With the suite clean, filterwarnings gains a leading error, so a warning introduced by our own
code fails the PR that introduces it rather than accumulating in the summary. Reasoning:

• Nothing in this repo calls warnings.warn or pytest.warns, so there is no intentional warning
  for error to break.
• The cost is real but acceptable: a dependency upgrade that adds a new upstream warning now fails
  loudly and needs an entry here. That is the intended trade, and it matches why the ruff rule
  selection is already pinned in this file — an upgrade should change behaviour visibly, not
  silently.
• Later entries win, so error goes first and both ignores are applied on top of it.
• Verified on the default suite and on the network-gated test (uv run pytest --run-network,
  which error also covers and which is skipped by default, so it would otherwise go unchecked).

Verification

uv run ruff check .              All checks passed!
uv run ruff format .             200 files left unchanged
uv run --all-packages ty check   All checks passed!
uv run pytest                    395 passed, 1 skipped in 49.80s

No warnings summary, and no stray tracebacks after it.

🤖 Generated with Claude Code

[JackKelly]

Review pass — what changed, and one thing deliberately left alone

An adversarial review of the first commit raised six findings. Five are addressed in 2fdeb75; the
sixth was flagged as out of scope — Jack has since asked for it, and it is now fixed (see below).

Fixed

1. Both ignore entries were unanchored prefixes. module is matched with re.match, so
   …sql_event_log also accepted a hypothetical …sql_event_log_v2. Both entries now end in $.
2. The pre-existing mlflow entry did not meet the standard my own new comment block asserts — no
   version, no delete condition, an unescaped . in the message, and a whole-package mlflow.*
   anchor. Now pinned like the Dagster one. Worth noting: the review asserted the exact raising
   module was mlflow.utils.yaml_utils; that is what the traceback shows, but it is wrong.
   codecs.open() is called from two mlflow modules, and anchoring on yaml_utils alone fails
   five tests. The entry enumerates mlflow\.utils\.(file_utils|yaml_utils)$.
3. The riskiest claim was untested. live_forecasts_schedule is built by
   build_schedule_from_partitioned_job, so its cron is derived from the inferred
   partitions_def — exactly what removing the explicit argument could have broken — and nothing
   asserted it. test_definitions_resolve now pins the resolved schedule's cron and timezone, and
   live_forecasts_job has been added to the asset-selection loop it was missing from.
4. is → == on the new partitions assertions. Identity is stronger than the property under
   test. == still catches None and any cadence/start difference, and is what Dagster's own
   inference uses internally, so it will not go red if Dagster ever returns an equal copy.
5. Documented both new repo-wide rules in docs/architecture/testing.md — they were previously
   discoverable only from a docstring and a TOML comment. Plus a stray blank line from the scripted
   refactor.

---

Not fixed — out of scope → Now fixed (53d717e, diagnosis corrected in afb91df)

scripts/run_baseline_experiment.py:124 has the same leak this PR diagnoses… I left it alone
because CLAUDE.md says not to make out-of-scope changes without asking.

Jack asked for it, so it is done: main() now uses with DagsterInstance.ephemeral() as instance:,
and the five pipeline steps moved into _run_pipeline(instance) rather than gaining a level of
indentation.

My original description of this leak was wrong, and measuring properly corrected it. I first
claimed the script's happy path was safe (the local is reclaimed on return) and that only an
unhandled exception could keep the instance alive to shutdown. That measurement stubbed
materialize out — and stubbing materialize is exactly what removed the retention. With a real
materialize, Dagster keeps the instance reachable for the rest of the process (a RunDomain, plus
the partition-loading contexts holding it as dynamic_partitions_store, confirmed via
gc.get_referrers).

Re-measured with one real materialize, counting storages whose held connection is still open at
interpreter exit:

	bare call	with context manager
happy path	2 open	0 open
error path	2 open	0 open

So the context manager is not error-path insurance — it is the only thing that closes these
connections at all. docs/architecture/testing.md and the code comment were corrected in afb91df;
the code fix itself was right from the start.

Observable behaviour is unchanged: happy-path stdout is byte-identical, and on failure the exception
still propagates with exit code 1, skipping _report_metrics() and the closing "Done." line. The
other two Python scripts create no Dagster instance and no DB connection, so this was the only
remaining site.