title: Clearing cached service container fails due to the cached service container
body: <p>My question here boils down to whether what I'm doing in and of itself is wrong or whether I have discovered a bug. I'm simply not sure...</p>
  
  <p>What did I do? We have a relatively normal application based on Symfony 2.8. There, we also use the usual service container. Also, for maintenance, we define a bunch of commands to call on the commandline. During development, I added another parameter to the constructor of a class which is used in one of these commands.</p>
  
  <p>The problem I have now is that I can't properly deploy this. When I just replace the code and call <code>app/console cache:clear</code> to regenerate the cached service container from the services definition, because on startup, the kernel tries to instantiate all commands using the cached service container. Since the cached service doesn't provide the new parameter but the changed code requires the parameter, startup fails.</p>
  
  <p>Further observations:</p>
  
  <ul>
  <li>The command extends the <code>setContainer()</code> method from the baseclass to retrieve its own dependencies. In this case, one commands fails to retrieve its dependencies from the service container. I'm wondering if <code>setContainer()</code> is too early -- If I postponed this to <code>execute()</code>, this would only fail when the command is actually invoked but not when <code>cache:clear</code> is invoked.</li>
  <li>I'm also thinking that Symfony shouldn't abort startup if initialization of some command fails. It should alert the user but continue loading other commands. Even more, it shouldn't even load commands that aren't used.</li>
  <li>In my particular case, I think that just not loading that command (or skipping it on error) would do the job, but I'm not sure if that is always the case.</li>
  <li>As workaround, I can of course delete the cache folder. But what's the point of a <code>cache:clear</code> command if that doesn't work?</li>
  </ul>