Consider replacing EntityLastInstalledSchemaRepositoryInterface with EntityFieldManager in taxonomy_post_update_make_taxonomy_term_revisionable

@Adam i tried #4 patch , issue still exist .

Hi @adam ,

As per you request i am uploading the error .

 [notice] Update started: taxonomy_post_update_make_taxonomy_term_revisionable
 [error]  Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'status' cannot be null: INSERT INTO {tmp_853997taxonomy_term_field_data} (tid, revision_id, vid, langcode, status, name, description__value, description__format, weight, changed, default_langcode, revision_translation_affected) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11); Array
(
    [:db_insert_placeholder_0] => 1
    [:db_insert_placeholder_1] => 1
    [:db_insert_placeholder_2] => category
    [:db_insert_placeholder_3] => en
    [:db_insert_placeholder_4] => 
    [:db_insert_placeholder_5] => Pets
    [:db_insert_placeholder_6] => 
    [:db_insert_placeholder_7] => 
    [:db_insert_placeholder_8] => 0
    [:db_insert_placeholder_9] => 1536043409
    [:db_insert_placeholder_10] => 1
    [:db_insert_placeholder_11] => 1
)

I'm not sure this is the correct approach. It looks like somehow your FieldStorageConfig has got out of sync with the entity.last_installed_schema.repository. #3061950-9: SQLContentEntityStorage::saveToDedicatedTables() doesn't correctly use storage configuration is possible solution for getting them back in sync.

As to why they're out of sync, not sure. It's quite likely a source of a quite a few of the 8.7 upgrade issues. But if you get them back in sync taxonomy_post_update_make_taxonomy_term_revisionable() update should go through without issue.

I also hit this same error, but in my case it was due to certain field.storage.taxonomy_term.* having null or unset UUIDs (not sure how, but very likely due to some previous manual creation/syncing of these config entities). So the solution was to ensure UUIDs were consistent across the storage config and last_installed_schema.

@fenstrat I had that same issue too - my UUIDs didn't match between the last installed schema and my actual field definitions - probably due to some misguided config management a long time ago (oops!) . Even though that was a mistake, it does seem odd to have one thing define the table for creation, and another for writing to it. That just seems like unnecessary potential for problems.

Of course the expectation is that the last_installed_schema values ought to be correct, but I don't think that needs to be relied upon when the field manager could just be used (as in the patch). I wouldn't even mind if it was the other way round, to use the last installed schema definition when creating the temporary table, instead of the current field definition? I haven't thought much about which way around it should be.

#13 is correct, this approach is not viable because the point of an update function is to be able to rely on a known definition (like the one provided by installed entity definition repository), while using the live definitions (i.e. the ones returned by the field manager by default) will make an update function return unexpected/different results, depending on the time and the state of the codebase when it is run.

However, the reports about different UUID between the live and last installed definitions is interesting and I think those should show up in the mismatched entity/field definitions list on the status report page. I've opened a separate issue to track this: #3101598: Differring field storage identifiers should be reported as a missing field storage definition update