Thanks to visit codestin.com
Credit goes to github.com

Skip to content

MNT Don't ship RecordingCallback.record to the workers - #34811

Merged
jeremiedbb merged 1 commit into
scikit-learn:mainfrom
jeremiedbb:fix-recording-callback-record
Aug 25, 2026
Merged

MNT Don't ship RecordingCallback.record to the workers#34811
jeremiedbb merged 1 commit into
scikit-learn:mainfrom
jeremiedbb:fix-recording-callback-record

Conversation

@jeremiedbb

Copy link
Copy Markdown
Member

For public callbacks we make sure to only store plain data on the callback instances. But RecordingCallback is there for testing purpose, to check the context tree or the passed estimator for instance so we want to store whole objects.

The thing is that the context holds a reference to the callback which itself holds a reference to the record. So we end up nesting the record into the record which makes it grow exponentially.

We assumed that since it would only be used it tests it would be fine but as we grow and strengthen the tests, it looks like it's not fine anymore.

The solution is to not ship the record when the callback is serialized and sent to the workers, because we never need to read the full record from a worker, only from the callback instance in the main process.

This should fix the issue from #34806, #34804
It should also fix #34792
(It already makes the callback test suite twice as fast so worth merging anyway)

ping @lesteve @FrancoisPgm

@lesteve

lesteve commented Aug 25, 2026

Copy link
Copy Markdown
Member

Thanks for the PR, this seems to fix the problem, even if I am not going to claim I understand why 😅.

I double-check that the following command does not fail in this PR:

pytest sklearn/callback/tests/test_callback_support.py \
    -k 'test_function_no_callback_support and RecordingCallback-processes-2' --count 50

On main, I get 50% failure rate, i.e. ~25 failures out of 50 repeats.

I am going to approve this PR, since this is only used in testing and let @FrancoisPgm do a more thorough review on the actual fix. @jeremiedbb feel free to merge once you have converged with @FrancoisPgm.

@FrancoisPgm FrancoisPgm left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jeremiedbb for catching that circular referencing. I'm ok with the fix, we'll just have to keep it in mind if we ever have to deep copy a RecordingCallback for some reason.

@jeremiedbb
jeremiedbb merged commit 32d5f59 into scikit-learn:main Aug 25, 2026
46 checks passed
prady0t pushed a commit to prady0t/scikit-learn that referenced this pull request Sep 2, 2026
@jeremiedbb
jeremiedbb deleted the fix-recording-callback-record branch September 3, 2026 15:25
@jeremiedbb jeremiedbb mentioned this pull request Sep 8, 2026
14 tasks
jeremiedbb added a commit to jeremiedbb/scikit-learn that referenced this pull request Sep 8, 2026
jeremiedbb added a commit to jeremiedbb/scikit-learn that referenced this pull request Sep 9, 2026
jeremiedbb added a commit to jeremiedbb/scikit-learn that referenced this pull request Sep 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Race when pickling RecordingCallback during process-based parallelism on Python 3.14

3 participants