Codex flagged on #783: _populate_sd_cache's hash key includes the op chain (and, since #785, id(sampled_df) + post_processing_method) but not the active analysis_klasses. When analysis_klasses changes — e.g. add_analysis() is called, or a custom dataflow swaps the set — the SD semantics change, but the cache key stays identical to the previous configuration's, so the new analyses' output is masked by a stale hit.
The fix is the same pattern as the P1 / post-processing folds in #785: include a stable identifier for the active analysis set in the extra arg of hash_chain. A name-tuple of the analysis classes is probably sufficient — full stability across processes isn't needed since the cache is process-local.
Out of scope for #785; that PR explicitly defers this. Marking as low priority because the user-visible scenarios that trip it (e.g. add_analysis after the cache has populated) are uncommon and resolved by widget reconstruction today.
🤖 Generated with Claude Code
Codex flagged on #783:
_populate_sd_cache's hash key includes the op chain (and, since #785,id(sampled_df)+post_processing_method) but not the activeanalysis_klasses. Whenanalysis_klasseschanges — e.g.add_analysis()is called, or a custom dataflow swaps the set — the SD semantics change, but the cache key stays identical to the previous configuration's, so the new analyses' output is masked by a stale hit.The fix is the same pattern as the P1 / post-processing folds in #785: include a stable identifier for the active analysis set in the
extraarg ofhash_chain. A name-tuple of the analysis classes is probably sufficient — full stability across processes isn't needed since the cache is process-local.Out of scope for #785; that PR explicitly defers this. Marking as low priority because the user-visible scenarios that trip it (e.g.
add_analysisafter the cache has populated) are uncommon and resolved by widget reconstruction today.🤖 Generated with Claude Code