So, this happens when the DI extension doesn't callExtension::processConfiguration(), which is the case in PropelBundle (fixed inpropelorm/PropelBundle#461.)

Shouldn't be common, so I wouldn't recommend a new release (yet.)

@nicolas-grekas Thanks! I can confirm:

1. It works with your PropelBundle fix, without this pr
2. It works with your pr without changing PropelBundle
3. And of course, it also works with both changes together.

Hi guys, thanks for the fix!

What about release that one since every bundle without the fix may have issue?

@gharlan confirms that this PR fix the issue without change in the bundles.

@jeremyFreeAgent if you have the issue (do you?), you'd better fix it in your bundle also because its current behavior will prevent correct tracking of ENV vars anyway.

@nicolas-grekas I was not talking aboutmy bundle but thecommunity bundles. I mean okay we can PR every bundle we spot with that issue but what aboutbasic users of Symfony that will only update Symfony and expect everything still works?

BTW I have PR the fix insymfonycorp/connect-bundle#17 and It was merged :)

I can confirm the same bug using 8p/guzzle-bundle.

@samvdb can you submit a PR onhttps://github.com/8p/GuzzleBundle/blob/master/DependencyInjection/GuzzleExtension.php to fix that extension the same way as done insymfonycorp/connect-bundle#17?

BTW, I'll propose to deprecate not callingExtension::processConfiguration() in 3.4, and throw an exception in 4.0

@nicolas-grekas PR is open, can confirm this fixes the issue.
8p/EightPointsGuzzleBundle#120

@nicolas-grekas could we detect that this method was not called, and use the previous behavior for replacing env placeholders in this case ? This would not solve the shadowing of the config in case a variable is not used anymore in the end. But it would mean that the contain keeps working when the config is now shadowed.
Otherwise, it means we broke BC in a patch version.

@stof see patch, that should be what L97 does.

Thank you@nicolas-grekas.