Magento2: Import failed: Unable to unserialize value, string is corrupted

Created on 31 Oct 2017  路  18Comments  路  Source: magento/magento2


Preconditions


  1. Magneto 2.2.0 RC3

Steps to reproduce

  1. bin/magento setup:upgrade

Expected result


For the data config to be updated

Actual result

  1. Import failed: Unable to unserialize value, string is corrupted.

Temporary Work Around

UPDATE flag SET flag_data = '{"system":"","scopes":"","themes":""}' WHERE flag_code = 'config_hash';
UPDATE flag SET flag_data = '{}' WHERE flag_code = 'system_config_snapshot'; 

Flush Cache
Run bin/magento setup:upgrade or bin/magento app:config:import.

Format is valid non-issue

Most helpful comment

I spontaneously had this issue when dumping and importing my config, zero issues prior.

@LiamKarlMitchell posted the fix. The issue was that the flag_data table was too small and the JSON was cut off prematurely.

Any chance we can get the default size of the table to be longtext?

Magento 2.3.3.

All 18 comments

It looks to me like the Worldpay_Payments module has not been updated to use the new Magento 2.2 serialization methods. Most likely there is data that needs to be converted from PHP serialization to JSON, and the module itself may need to be updated to use the new serialization classes.

@Silarn you are right!

@DavaGordon please make sure all third party extensions are compatible with 2.2 prior to upgrade, Magento cannot fix them for you. Check http://devdocs.magento.com/guides/v2.2/release-notes/backward-incompatible-changes.html#database-data-format-changes for this particular issue solution.

It was actually falling over at MageWorx Seo which i actually removed from magento earlier that day for some reason it still saw the module as being installed after removing from setup_module everything worked fine

@DavaGordon how did you find out it was the MageWox module? I'm running into the same issue but I haven't found the error yet.

@Tjitse-E process of elimination i outputted the deployment function which worked fine up until that one so i disabled it and after this it deployed perfectly fine

@orlangur I always use the CLI to uninstall modules but it did not remove the module from the DB need to do manually to fix the issue

@DavaGordon thanks for your reply. My issue wasn't actually in a third party module, but in the flagtable (more info: https://github.com/magento/magento2/issues/11657).

I have the same issue, but it is caused by something more serious: The flag_data field in the flag table is too short to contain the whole json config.

That field is a TEXT field, so it can contain 65,535 chars. My serialized json is 71,347 so it is truncated at the end and it is not valid json anymore.

@orlangur can you take another look on this issue please?

@giacmir looks like issue mentioned in https://github.com/magento/magento2/issues/11899#issuecomment-343855250 already tracks the problem you describe.

@orlangur we are still hitting this with every client install due to the size of the config json being stored. (As per the comment made by @giacmir ).

@PeteZero1 corresponding issue is still open.

Still a problem, I just want to be able to edit options in the UI again, when I edit in config file I can't re-import as its corrupted?

Fix appears to be increasing the length of the flag tables flag_data from text to longtext as mysql likes to silently truncate the text data if it is too long as it was on a site I am maintaining. I can't help but think that is a silly amount of data to store in 1 field..

I saw this mentioned here on step 5
https://magento.stackexchange.com/questions/196912/appconfigdump-locks-everything-in-configuration

ALTER TABLE `flag` 
MODIFY COLUMN `flag_data` longtext CHARACTER SET utf8 COLLATE utf8_general_ci NULL COMMENT 'Flag Data' AFTER `state`;

After which you can do a dump, then an import.
In my case I had to do some minor tweaks to the config.php so it could import.

Such as changing '[]' to a NULL and changing some other settings for weltpixel things to "" rather than NULL.

But I still can't seem to edit the values in the admin screens, they are all grayed out :(.

@orlangur sorry, what is corresponding issue are you referencing? This issue is the only one I am aware of and I believe it was closed but the issue still remains? (Not the direct fault of a 3rd party module, but additional data added by 3rd party modules is causing core to fail)
Apologizes if there is another issue I am not aware of.

I spontaneously had this issue when dumping and importing my config, zero issues prior.

@LiamKarlMitchell posted the fix. The issue was that the flag_data table was too small and the JSON was cut off prematurely.

Any chance we can get the default size of the table to be longtext?

Magento 2.3.3.

Got this issue today, 2.3.3-p1 flabbergasted to see that this is a "non-issue"

Still a problem, I just want to be able to edit options in the UI again, when I edit in config file I can't re-import as its corrupted?

Fix appears to be increasing the length of the flag tables flag_data from text to longtext as mysql likes to silently truncate the text data if it is too long as it was on a site I am maintaining. I can't help but think that is a silly amount of data to store in 1 field..

I saw this mentioned here on step 5
https://magento.stackexchange.com/questions/196912/appconfigdump-locks-everything-in-configuration

ALTER TABLE `flag` 
MODIFY COLUMN `flag_data` longtext CHARACTER SET utf8 COLLATE utf8_general_ci NULL COMMENT 'Flag Data' AFTER `state`;

After which you can do a dump, then an import.
In my case I had to do some minor tweaks to the config.php so it could import.

Such as changing '[]' to a NULL and changing some other settings for weltpixel things to "" rather than NULL.

But I still can't seem to edit the values in the admin screens, they are all grayed out :(.

They are greyed out because someone has dumped them Into the config.php in app/etc you can remove the option arrays in here giving you backend access again

Got this issue today, 2.3.3-p1 flabbergasted to see that this is a "non-issue"

Dude, just been there, right this second

Dunno if anyone will find this helpful but I found that I had a configuration issue in my env.php whereby I had 2 areas referencing different databases:

'db' => [
        'connection' => [
            'indexer' => [
                'host' => 'mysql',
                'dbname' => 'my_db_2',
                'username' => 'user',
                'password' => 'pass',
                'active' => '1',
                'persistent' => NULL,
                'model' => 'mysql4',
                'engine' => 'innodb',
                'initStatements' => 'SET NAMES utf8;'
            ],
            'default' => [
                'host' => 'mysql',
                'dbname' => 'my_db_1',
                'username' => 'user',
                'password' => 'pass',
                'active' => '1',
                'model' => 'mysql4',
                'engine' => 'innodb',
                'initStatements' => 'SET NAMES utf8;'
            ]
        ],
        'table_prefix' => ''
    ],

Had my_db_1 in 1 and my_db_2 in the other. Upon matching these I ran:

php bin/magento app:config:import && \
php bin/magento setup:upgrade && \
php bin/magento cache:flush

And the configuration was no longer greyed out / disabled / unchangeable.

Was this page helpful?
0 / 5 - 0 ratings