Do not mutate the source transformer config in SD3ControlNetModel.from_transformer

[Devam0311]

Issue link: this addresses Issue 4 of #13611.
I have deliberately not used a Fixes keyword: #13611 tracks 6 separate findings, so a closing keyword would close it as soon as this one merges while the others are still open. Happy for the no-issue-needed label to be applied, or I can add a closing keyword if you would rather the review issue be closed and reopened.

What does this PR do?

Fixes Issue 4 of #13611 (stable_diffusion_3 model/pipeline review).

SD3ControlNetModel.from_transformer bound config = transformer.config, which aliases the transformer's live config, and then wrote ControlNet-specific values into it. Building a ControlNet therefore mutated the transformer it was built from.

Reproduced on main:

before: num_layers = 3 | has extra_conditioning_channels = False
after : num_layers = 1 | extra_conditioning_channels = 2

The source transformer's num_layers is overwritten and an unrelated extra_conditioning_channels key is injected, which can corrupt later serialization, logging, or any pipeline construction that reuses that transformer.

Solution

Copy the config before mutating it — which is what the sibling ControlNets already do:

Model
controlnet_flux.py:135	config = dict(transformer.config)
controlnet_qwenimage.py:113	config = dict(transformer.config)
controlnet_sd3.py:257	config = transformer.config ← fixed here

config = dict(transformer.config)
config["num_layers"] = num_layers or transformer.config.num_layers

The num_layers fallback now reads from transformer.config rather than the copied dict, since a plain dict has no attribute access.

I also checked controlnet_hunyuan.py:177, which binds the config the same way but only ever reads attributes from it and never writes, so it is not affected and is left alone.

Testing

New tests/models/controlnets/test_models_controlnet_sd3.py:

• test_from_transformer_does_not_mutate_source_config — the regression itself
• test_from_transformer_applies_controlnet_config — the overrides still reach the ControlNet
• test_from_transformer_num_layers_falls_back_to_transformer — covers the num_layers=None path, which the rewritten fallback touches

Verified the regression test actually catches the bug: with the fix reverted it fails, with it applied it passes.

pytest tests/models/controlnets/test_models_controlnet_sd3.py   -> 3 passed
pytest tests/pipelines/controlnet_sd3/                          -> all passed
ruff check / ruff format --check                                -> clean
git diff --check                                                -> clean

Note: tests/models/controlnets/test_models_controlnet_cosmos.py has 7 failures, but they reproduce identically on a clean checkout of main here, so they are unrelated to this change.

Before submitting

• Did you use an AI agent (Claude Code, Codex, Cursor, etc.) to help with this PR? If so:
  • Did you read the Coding with AI agents guide?
  • Did you run the self-review skill on the diff?
  • Did you share the final self-review notes in the PR description or a comment?
• Did you read the contributor guideline?
• Was this discussed/approved via a GitHub issue? — stable_diffusion_3 model/pipeline review #13611
• Did you write any new necessary tests?

Self-review notes

Reviewed against .ai/references/review-rules.md, models.md and testing.md. No blocking issues.

For the reviewer:

1. tests/models/controlnets/ previously held only the Cosmos file, and there were no from_transformer tests anywhere in the suite. I added a small focused file rather than wiring up the full BaseModelTesterConfig mixin suite, which felt like scope creep for a one-line fix — happy to expand it if you'd rather it be a full model tester.
2. Scope kept to Issue 4. stable_diffusion_3 model/pipeline review #13611 lists six issues; Issue 1 is in Apply the VAE shift factor when decoding in SD3 inpaint #14671, and the rest are untouched.
3. This is behaviour-preserving for the returned ControlNet — only the side effect on the source transformer changes.

Who can review?

@yiyixuxu @DN6 @hlky

[github-actions]

Hi @Devam0311, thanks for the PR! It does not appear to link an issue it fixes. If this PR addresses an existing issue, please add a closing keyword (e.g. Fixes #1234) to the PR description so the issue is linked. See the contribution guide for more details. If this PR intentionally does not fix a tracked issue, a maintainer can add the no-issue-needed label to silence this reminder.

Please note that PRs without a linked issue are likely to be automatically closed 10 days after this notice.

Once the PR links an issue (or gets the no-issue-needed label), you can ignore this message — it stays here as a comment, but it no longer applies.

[github-actions]

This PR has been automatically closed because it does not link an issue and the reminder above was not addressed within 10 days. If this PR is still relevant, please link the issue it fixes (e.g. Fixes #1234) or ask a maintainer to add the no-issue-needed label, and it can be reopened.

We are experimenting with this process to keep the review queue manageable, and it will sometimes get it wrong. If you think this PR should stay open, please just say so here and we will reopen it — no need to justify it at length.

Thanks again for contributing, and sorry for the noise if we closed this by mistake!