Note that this isn't a blocking error -- it's a mostly informational error. It actually just leaves the serialized content in the column if it fails (which will implicitly decode to an empty array as is, since the JSON encode will fail). So you could theoretically manipulate it in 2.1 as the code is at this instant.
However, the approach taken here was conservative in the sense that we didn't want to wipe out content in the DB during the upgrade and wanted to see if we had any error reports from people doing upgrades; this is the first one that I recall seeing (and it's actually the table I was expecting as I vaguely remember some related issues in the past). There is potentially an option to use the
However, the approach taken here was conservative in the sense that we didn't want to wipe out content in the DB during the upgrade and wanted to see if we had any error reports from people doing upgrades; this is the first one that I recall seeing (and it's actually the table I was expecting as I vaguely remember some related issues in the past). There is potentially an option to use the
JSON_PARTIAL_OUTPUT_ON_ERROR
flag on these conversions. This will strip out anything that it can't JSON encode, while keeping most data, but that does mean removing content from the table and it won't be recoverable. We may be adjusting the code to that -- I've kept that bug open mostly for that reason.