Skip to content

Refresh cached SearchUpdater when AbstractSearch.paths is reassigned#1252

Merged
Jammy2211 merged 1 commit into
mainfrom
feature/search-updater-paths-refresh
May 4, 2026
Merged

Refresh cached SearchUpdater when AbstractSearch.paths is reassigned#1252
Jammy2211 merged 1 commit into
mainfrom
feature/search-updater-paths-refresh

Conversation

@Jammy2211
Copy link
Copy Markdown
Collaborator

Summary

AbstractSearch._updater lazy-caches a SearchUpdater on first access and previously never invalidated the cache. When the EP loop reuses one search instance across factors and iterations, AbstractSearch.optimise(factor_approx) reassigns self.paths to a fresh SubDirectoryPaths per factor and per EP iteration — but the updater stayed pinned to the very first paths it ever saw. Result: every per-factor / per-iteration sample, visualisation, and profile output silently wrote under the first iteration's directory, with each later iteration overwriting the earlier one. The user-visible symptom is that an Analysis.Visualizer only ever produces output under dataset_<i>/optimization_0/image/, never under optimization_1/, optimization_2/, etc.

The fix is one identity check in the _updater property: if the cached updater's _paths is no longer the search's current self.paths, recreate the updater. Identity (is not) is the right test — AbstractSearch.optimise always assigns a freshly-constructed SubDirectoryPaths, never an in-place mutation. Plus a unit test that simulates the EP path-mutation pattern (assign search.paths = af.DirectoryPaths(...) and check _updater._paths is search.paths).

End-to-end verified on the cancer-IC50 EP validation script: 10 datasets × 3 EP iterations now produces 30 per-iteration Hill-curve fit plots correctly distributed across dataset_0..9 / optimization_0..2. Before the fix the same script produced only 10 plots, all in the iter-1 directory.

API Changes

None — internal change only. Existing callers see no behaviour difference unless they were affected by the bug. The _updater property remains a private cached lazily-initialised SearchUpdater; the only difference is that it now refreshes when the search's paths attribute has been reassigned to a new object.

Test Plan

  • pytest test_autofit/non_linear/search/test_abstract_search.py::TestUpdaterPathsRefresh — new test
  • pytest test_autofit/non_linear test_autofit/graphical -q — 426 tests pass (no regressions)
  • End-to-end on cancer-IC50 EP fit (10 datasets × 3 EP iterations): 30 per-iteration hill_curve_fit.png plots distributed correctly across dataset_<i> / optimization_<j> (was 10 plots, all in optimization_0, before the fix)
Full API Changes (for automation & release notes)

Changed Behaviour

  • autofit.non_linear.search.abstract_search.AbstractSearch._updater — the cached SearchUpdater is now invalidated and recreated when self.paths is reassigned to a different object. Previously it was created once on first access and reused forever, regardless of subsequent self.paths reassignments. Identity comparison (is not) is used as the cache-invalidation key.

Migration

None required — the property is private and the bug fix removes a silent behaviour that no correct caller could have relied on.

🤖 Generated with Claude Code

``AbstractSearch._updater`` lazily caches a ``SearchUpdater`` on first
access and previously never invalidated the cache. When the EP loop
reuses a single search across factors and iterations,
``AbstractSearch.optimise(factor_approx)`` mutates ``self.paths`` to a
fresh ``SubDirectoryPaths`` per factor and per EP iteration — but the
updater stayed pinned to the first paths it ever saw, so all
subsequent samples / visualizations / profiles wrote under the wrong
directory. The user-visible symptom is per-EP-iteration visualisations
overwriting each other in the first iteration's image folder.

Identity-comparing the cached updater's ``_paths`` against
``self.paths`` makes the property recreate the updater whenever the
search has been pointed at a new paths object.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@Jammy2211 Jammy2211 added the pending-release PR queued for the next release build label May 4, 2026
@Jammy2211 Jammy2211 merged commit 9472f40 into main May 4, 2026
3 checks passed
@Jammy2211 Jammy2211 deleted the feature/search-updater-paths-refresh branch May 4, 2026 18:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pending-release PR queued for the next release build

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant