Are there any pitfalls by combining n_jobs and random_state? #30809

No special fork bug with the default joblib path, but n_jobs can change how a shared RandomState is consumed across folds.

cross_val_score clones the estimator once per fold and runs those clones under joblib (sklearn.utils.parallel.Parallel). With random_state=RandomState(...), clones are statistical clones that share that same RNG object. With n_jobs=1, fold 2 sees the RNG after fold 1 advanced it. With n_jobs>1 (default loky backend), workers typically get pickled copies of the RNG state at dispatch, so folds do not chain advances the same way. CV scores can differ slightly between n_jobs=1 and n_jobs=-1 when the estimator holds a RandomState instance.

Integer seeds avoid that chaining. Each fit resets to the same seed, and that is stable across n_jobs. Your KFold(..., random_state=42) int seed is the right pattern for splitters.

From the Controlling randomness guide: int for splitters, RandomState (or None) on estimators if you want fold-wise estimator randomness, and do not expect bit-identical scores across different n_jobs when the estimator uses a RandomState instance.

Checked sklearn/model_selection/_validation.py (clone + Parallel), sklearn/base.py clone notes, and the common-pitfalls docs. I did not re-run a multi-process experiment here.