fix(history): give each MLflow run one owning task - #31
Merged
Conversation
mlflow's fluent active-run stack is thread-local and every concurrent request shares it, so overlapping runs ended and retagged each other and phantom runs appeared whenever the stack was empty. Bind every write to its own run id, terminate each run exactly once, sweep runs stranded RUNNING by a dead process at boot, and read Model and Result from where they are actually written. Closes mitre#29
HackedRico
force-pushed
the
fix/mlflow-run-lifecycle
branch
from
August 28, 2026 12:31
08474ad to
2671589
Compare
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.
Description
Fixes #29.
mlflow.tracking.fluent._active_run_stackis a thread-local, and every/plugin/mcp/executerequest is an asyncio task on one aiohttp event-loopthread. Concurrent runs therefore shared one active-run pointer, so a bare
end_run()terminated someone else's run, tags landed on the wrong run, and awrite with an empty stack silently minted a phantom run.
app/mlflow_run.py:RunTrackerbinds anMlflowClientto one run id.Writes are truncated and best effort so observability never fails the run it
describes;
terminate()writes once._run_executionand both workflows (author,plan_execute) drop the fluentAPI. A run handed in by
mcp_svcis terminated bymcp_svc; a run a workflowmints itself is terminated by that workflow.
hook.pyruns a boot-time sweep reconciling anyRUNNINGrun absent from thelive cache to
KILLED, which also clears existing residue.Modelcolumn now has amodelparam to read, andResultreads theprocess_resulttag instead of a param nothing ever wrote.KILLEDand shows-for its duration, since the sweeptimestamp is when we noticed, not when the run stopped.
Two side effects worth flagging: DSPy autolog traces are no longer attached to a
run (they still land in the experiment), and the sweep assumes one tracking
server per deployment, which is what
hook.pyalready provisions from yaml.Type of change
How Has This Been Tested?
17 new tests across
tests/test_mlflow_run_lifecycle.py,tests/test_run_execution_lifecycle.py, andtests/test_author_guards.py,covering overlapping runs, failure attribution, phantom-run absence, run
ownership, and the orphan sweep. Each was confirmed to fail against pre-fix code
and pass after. Verified against mlflow 3.15.1 and dspy 3.3.0.
Full plugin suite compared before and after in the same environment: no new
failures, 17 new passes. Remaining suite failures are pre-existing and
environmental (missing CTI extras, live-Caldera-dependent modules).
Checklist: