Skip to content

force_refresh also rebuilds the cached Owlery id list - #126

Open
Robbie1977 wants to merge 2 commits into
mainfrom
fix/force-refresh-reaches-owlery-ids
Open

Robbie1977 wants to merge 2 commits into
mainfrom
fix/force-refresh-reaches-owlery-ids

Conversation

@Robbie1977

Copy link
Copy Markdown
Contributor

Problem

force_refresh on an Owlery-based query (ImagesNeurons, NeuronsPartHere, PartsOf, ...) cleared only the finished result and then recomputed it from the still-cached Owlery id list (owlery_ids), so a refresh after a data load returned the same stale set. Seen on the cluster 2026-10-12: ImagesNeurons(FBbt_00040051) was 2678 cached vs 3206 live after the BANC v888 load, and three forced refreshes changed nothing. The server log shows it: Force refresh requested for images_neurons(...) followed by Cache hit for owlery_ids(...).

Fix

A forced call now sets a context flag (solr_result_cache.force_fresh_active()), and _owlery_query_to_results passes it to _owlery_ids_cached(force_refresh=...), so both layers are rebuilt.

  • get_term_info does not set the flag (its force path already fans out per query and forwards force_refresh where a query takes it).
  • A ContextVar, not a keyword, so cache field names don't split between refreshed and normal calls.

Tests

tests/test_force_refresh_owlery_ids.py (offline): the flag is off by default and reset after the call; term_info does not raise it; it reaches _owlery_ids_cached through get_images_neurons. Together with tests/test_force_refresh_header.py: 20 passed.

CACHING.md has a new section, "force_refresh and the Owlery id list".

…esult

A forced refresh cleared only the query result and recomputed it from the still-cached
owlery_ids layer, so after a data load (new BANC neurons) it returned the same stale set.
Raise a context flag for the duration of a forced call and pass it to _owlery_ids_cached.
get_term_info is excluded (its force path already fans out per query).
@github-actions

Copy link
Copy Markdown

⚠️ 58 test(s) skipped — an upstream data source was unreachable

The full suite ran, but 58 test(s) were skipped because an upstream data source (VFB's Neo4j / SOLR / Owlery, or FlyBase's Chado) did not answer during this run.

These are not failures and not a problem with this branch — but those queries went unverified, so a green check here is an incomplete run.

To re-run: open this workflow run and click Re-run all jobs once the data sources are healthy (re-running the “Run completeness” check itself does nothing — it has no job behind it).

8 failed, 836 passed, 58 skipped, 340 warnings in 2304.33s (0:38:24)

Posted automatically. This comment is removed once a run completes with zero skips.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant