Repository navigation
fix(runners): a runner no longer reuses another runner's cached steps - #78
Merged
Merged
Conversation
FleetRunner builds its steps lazily and caches them per process. The cache was keyed by (interface, name) only, so with njobs=1, threads or a reused worker pool, a second runner in the same process reused the first runner's steps and their parameters (e.g. its parser with or without the airport fuel file, its bada_path). The default settings were not affected. Each make_step_func callable now gets a unique token stored with the cached step; another token rebuilds and replaces the entry. Within one runner the token travels with the pickled callable, so each worker still builds each step once. At most one step per (interface, name) is kept. Tests: two callables keep their own params; one callable (and its pickled copies) builds once per process; two FleetRunners in one process (njobs=1) each apply their own airport fuel file, in both orders. The bug tests fail on the previous code. Audit: new item I11. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
joblib runs every task in the calling process when only one CPU is usable, so a 1-core job or container with the default settings was also affected. Code comment and audit I11 corrected (review finding); note that concurrent runners in one process rebuild their steps. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A FleetRunner does not build its steps (parser, BADA performance model, emissions, climate)
once at the start. Each worker process builds them the first time it needs them and keeps
them in a per-process cache, so the next batch of flights reuses them.
That cache was looked up by step name only ("neats" parser, "bada" performance, ...), not by
the settings the step was built with. So if a second runner ran in the same Python process,
it got the steps built for the first runner, with the first runner's settings.
Example (both runners in one Python session, njobs=1):
Before this fix, r2 used r1's parser, built without the airport fuel file, so AF was silently
ignored. In the opposite order, the second runner applied a file it was not given. The same
holds for any step setting (bada_path, emission or climate parameters).
Who is affected
Only when one Python process runs two or more runners with different settings, AND the steps
run inside that process or in reused workers:
calling process).
Typical cases: a notebook, a script comparing two configurations, the test suite.
A normal production run (one runner per process, default settings, several CPUs) was not
affected, so past results are unchanged.
Fix
Each runner's step gets its own token when the runner is created. The cache keeps the token
next to the step: a runner with another token builds its own step. Within one runner the
token is the same in every worker, so each worker still builds each step only once
(no slowdown). At most one step per type is kept in memory, as before.
Checks
with and without the airport fuel file, in both orders. The 3 bug tests fail on the old code.