Сбой очистки кэшированного сервисного контейнера из-за кэшированного сервисного контейнера

Мой вопрос здесь сводится к тому, является ли то, что я делаю, само по себе неправильно, или я обнаружил ошибку. Я просто не уверен …

Что я сделал? У нас относительно нормальное приложение на базе Symfony 2.8. Там мы также используем обычный сервисный контейнер. Также для обслуживания мы определяем группу команд для вызова в командной строке. Во время разработки я добавил еще один параметр в конструктор класса, который используется в одной из этих команд.

Проблема у меня сейчас в том, что я не могу правильно развернуть это. Когда я просто заменяю код и звоню app/console cache:clear для регенерации кэшированного сервисного контейнера из определения сервисов, потому что при запуске ядро ​​пытается создать все команды с использованием кэшированного сервисного контейнера. Поскольку кэшированная служба не предоставляет новый параметр, но измененный код требует этот параметр, запуск завершается неудачно.

Дальнейшие наблюдения:

• Команда расширяет setContainer() метод из базового класса для извлечения собственных зависимостей. В этом случае одна команда не может получить свои зависимости из сервисного контейнера. Мне интересно, если setContainer() слишком рано — если я отложил это execute(), это может произойти только тогда, когда команда действительно вызвана, но не когда cache:clear вызывается.
• Я также думаю, что Symfony не должен прерывать запуск, если инициализация какой-либо команды не удалась. Это должно предупредить пользователя, но продолжить загрузку других команд. Более того, он даже не должен загружать команды, которые не используются.
• В моем конкретном случае, я думаю, что просто не загружая эту команду (или пропуская ее по ошибке), можно сделать эту работу, но я не уверен, что это всегда так.
• Как обходной путь, я, конечно, могу удалить папку кеша. Но какой смысл cache:clear команда, если это не работает?