Thank you for your PR! Since we're approaching the year-end and New Year holidays, I'll review the details after New Year's Day.

Thank you for the update! I completely understand.
Please take your time, and I’m happy to follow up after New Year’s.

This pull request has not seen any recent activity.

Thank you for waiting.
I haven't been able to reproduce the original bug report. Did you manage to reproduce it in your environment?

Thanks for checking!

Yes, I was able to reproduce the issue locally under parallel execution. The key requirement is running OptunaSearchCV with n_jobs > 1 and passing a stateful callback (e.g., LightGBM early stopping) via fit_params.

I used a setup similar to the following (simplified):

early_stop = lgb.early_stopping(stopping_rounds=10)

oscv = OptunaSearchCV(
    lgb.LGBMClassifier(n_estimators=100, verbose=-1),
    param_distributions={
        "learning_rate": optuna.distributions.FloatDistribution(0.01, 0.2),
        "num_leaves": optuna.distributions.IntDistribution(10, 20),
    },
    cv=3,
    n_jobs=2,
    n_trials=4,
)

oscv.fit(
    X_train,
    y_train,
    eval_set=[(X_test, y_test)],
    eval_metric="auc",
    callbacks=[early_stop],  # shared callback instance
)

In this configuration, the callback object inside fit_params["callbacks"] is shared across parallel workers. As a result, multiple trials mutate the same callback state (e.g., best_iteration_), which causes cross-trial interference. This typically manifests as identical or prematurely stopped iteration counts across different trials rather than a hard crash.

The behavior is timing- and backend-dependent, so it may not reproduce deterministically in all environments, but the underlying issue is the shared mutable callback state.

The proposed fix:
This isolates the callback instances per worker by shallow-copying fit_params and deep-copying only the callbacks list at execution time. This prevents shared-state corruption without unnecessarily duplicating large objects.

If helpful, I can also add this reproducer directly to the PR description or expand it further.

Thank you! Could you provide a reproducible example?

Thank you. Could you also share the console log? The original bug report mentions that "sometimes the two trials have the same best iteration," but I haven't seen this happen very often in my environment.

Agreed that this is intermittent and environment-dependent.

Below is a representative excerpt from one of my runs with n_jobs=2. One observable signal is that parallel fits report identical best_iteration values , despite being interleaved and using different hyperparameters:

Training until validation scores don't improve for 10 rounds
Training until validation scores don't improve for 10 rounds
Early stopping, best iteration is:
[2]     valid_0's auc: 0.974949
Early stopping, best iteration is:
[2]     valid_0's auc: 0.974949

Training until validation scores don't improve for 10 rounds
Training until validation scores don't improve for 10 rounds
Early stopping, best iteration is:
[8]     valid_0's auc: 0.967273
Early stopping, best iteration is:
[8]     valid_0's auc: 0.967273

Training until validation scores don't improve for 10 rounds
Training until validation scores don't improve for 10 rounds
Early stopping, best iteration is:
[15]    valid_0's auc: 0.97697
Early stopping, best iteration is:
[15]    valid_0's auc: 0.97697

In the affected runs, parallel trials with different sampled hyperparameters occasionally reported identical best_iteration values, which is consistent with shared state in the early stopping callback.

In other runs, the issue manifests as premature stopping rather than identical iteration numbers, which is why it may not reproduce consistently.

Isolating the callback instances per worker removes this behavior entirely.