magento2: Import failed: Area code not set: Area code must be set before starting a session.

We had to run an extra query (but maybe that is Magento Cloud specific, in our case when moving a database from one environment to the other). And we are just clearing the flag data instead of deleting them entirely, this probably doesn’t make a difference, but I’m not entirely sure. Anyway, maybe it helps:

UPDATE flag SET flag_data = NULL WHERE flag_code = 'system_config_snapshot';
UPDATE flag SET flag_data = NULL WHERE flag_code = 'config_hash';

Credits to @joeshelton-wagento who pointed me in this direction on Slack a couple of months ago 😃

I was able to work around the issue by deleting the system_config_snapshot flag.

DELETE FROM flag WHERE flag_code = 'system_config_snapshot';

In my case, I received the same error using either setup:upgrade or app:config:import.

I’ve triggered this error when building custom console commands. To get past it, I had to try to set the area code explicitly and catch a LocalizedException:

class FoobarCommand extends \Symfony\Component\Console\Command\Command
{
    private $state;

    public function __construct(\Magento\Framework\App\State $state)
    {
        $this->state = $state;
        parent::__construct();
    }

    // do configuring stuff

    protected function execute(\Symfony\Component\Console\Input\InputInterface $input,
                               \Symfony\Component\Console\Output\OutputInterface $output)
    {
        try {
            $this->state->setAreaCode(\Magento\Framework\App\Area::AREA_FRONTEND);
        } catch (\Magento\Framework\Exception\LocalizedException $exception) {
            // do error-catching stuff
        }
        // do processing stuff
    }
}

I’m not getting this error with vanilla Magento, so I can’t test or guarantee a solution. That said, the setup:upgrade class instantiates and runs an app:config:import object like so:

$importConfigCommand = $this->getApplication()->find(ConfigImportCommand::COMMAND_NAME);
...
$importConfigCommand->run($arrayInput, $output);

(From / vendor / magento / magento2-base / setup / src / Magento / Setup / Console / Command / UpgradeCommand.php)

So, someone having an area code problem with either app:config:import or setup:upgrade could attempt to set the area code in /vendor/magento/module-deploy/Console/Command/App/ConfigImportCommand.php to see if that gets them past the error, even if duct-taping the core is the furthest thing from a long-term solution.

@tuyennn Magento 2 is pretty hard to develop now days. There are just too many little triggers that might affect the stability of the platform.

I hope Magento team can make this better in the near future.

Hello @springerin, thank you for your report. We’ve acknowledged the issue and added to our backlog.

Also happens in Magento 2.3.0 with multiple sites/webstore/view when trying to install Mageplaza_StoreLocator.

As a temporary work around I modified vendor/magento/framework/Session/SessionManager.php

But agree that emulating the area code in the Setup/Upgrade php classes appears to be the better solution.

Needed to delete the module row from the setup_module table as it had schema-version set but data_version was null.

I recently encountered this issue as well. This time working on a Magento 2.1.X store.

We recently removed all command output in favour of logging. This caused the aforementioned “Area code not set: Area code must be set before starting a session.” exception to be thrown.

We fixed this by ensuring the command has output by writing a line to the console. ($output->writeln()).

The issue is the following: when your command has a dependency which somehow injects the SessionManager class, the \Magento\Framework\Session\SessionManager::start() function which is called in the constructor. Causes the class to attempt to initialize a session.

The reason why adding output to your console commands solves the problem is that headers are send and the session is never initialized. (\Magento\Framework\Session\SessionManager::isSessionExists)

I realize that this does not seem to be a proper future-proof solution, but at least it works!

In my case, I followed @hostep 's advice here: and had to make sure that there were no values set in my env.php which conflicted with what was saved in the system_config_snapshot value. Again for me, it was having system/default/catalog/search/engine/mysql in my env.php whereas a db dump I was importing had a value in the flag table saved in the system_config_snapshot json. So the gist of my situation was to make sure there’s no conflicting values between the two. Hope that helps someone.

Thanks for the tips.

have been nginx fan at all time 😃

Don’t remove the generated directory directly, as that will wipe out its .htaccess file. That would be a security hazard in Apache-hosted websites.

To remove generated files, use the approach recommended by the dev docs:

cd <your Magento install dir>
rm -rf generated/metadata/* generated/code/*

Note that it removes the contents of the metadata and code directories, not the directories themselves.

Just wanted to leave this here in case it helps someone. I had this same error and it was actually due to some formatting issues (line breaks) created by the config:dump command. This caused the import parsing to fail and the exception thrown was misleading. Hope this helps someone else!