Do not require user to re-run update 8302 to avoid error "user.field_pending_expire_sent field needs to be updated"

Created on 17 August 2022, over 2 years ago
Updated 8 July 2024, 5 months ago

Problem/Motivation

I maintain a number of sites with password_policy 8.x-3.1, and /admin/reports/status gives me the following error on all of them:

ERROR

ENTITY/FIELD DEFINITIONS

Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
User

The user.field_pending_expire_sent field needs to be updated.

Steps to reproduce

I can't reproduce this on a brand new site, so I'll set this to "support request" and not "bug report".

Proposed resolution

I am looking for some guidance on fixing this on all my production sites.

Remaining tasks

User interface changes

API changes

Data model changes

✨ Feature request
Status

Postponed: needs info

Version

3.1

Component

Code

Created by

πŸ‡¨πŸ‡¦Canada alberto56

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡¦πŸ‡ΊAustralia thomwilhelm Sydney

    I had the same issue, I fixed by using a new update hook that calls password_policy_update_8302() again.

    /**
     * Re-run password_policy_update_8302.
     *
     * To fix https://www.drupal.org/project/password_policy/issues/3304188
     */
    function MY_MODULE_update_8005(&$sandbox) {
      \Drupal::moduleHandler()->loadInclude("password_policy", "install", "password_policy");
      password_policy_update_8302($sandbox);
    }
    

    As comment #9 mentions, it would be interesting to get any further analysis on this. But this makes the error go away.

  • πŸ‡ΊπŸ‡ΈUnited States gatorjoe

    Thanks Thom, your hook resolved my issue. I am using your approach in #9 as this appears to be a recurring issue.

  • πŸ‡―πŸ‡΄Jordan Ahmad Khader

    to solve the issue I had to change config of field.storage.user.field_pending_expire_sent.yml default_config_hash to current default_config_hash: ZvoiwXXb5mezPNqbX59an4o8XOJGttVTsuSLOC1yGGo

  • seeing this issue as well on 4.0

  • πŸ‡³πŸ‡ΏNew Zealand jweowu

    It sounds like this is an ongoing problem.

    There doesn't seem to be any movement in resolving this (unless #12 is the correct solution in all cases), and I never got any clarifications from my questions in #9, so my inclination was to stick with 3.0 until this is known to be resolved (especially when #11 suggests the problem may recur). As such, I'm attaching a patch for running version 3.0 on Drupal 10 (which may or may not be adequate -- I'm in the middle of an upgrade process and have not tested).

    My understanding is that the issue was introduced in version 3.1 (possibly #2877040: Remove dependency on CTools β†’ or some side-effect thereof), but the inconsistency makes this seem like a core bug at heart, and researching this error more generally has turned up (a) numerous similar cases, and (b) ✨ Provide an easier way for developers to identify entity/field definition mismatches Active and from there, https://www.drupal.org/project/schema_diff β†’ which looks like it could be really invaluable for debugging this.

    Could those experiencing this issue please utilise this module and report back?

  • πŸ‡³πŸ‡ΏNew Zealand jweowu

    > the inconsistency makes this seem like a core bug at heart

    On which note, can people please indicate the latest core version of Drupal in which they've experienced this?

    I've seen it in Drupal 9.5, so I'm primarily wanting to know whether this is happening to anyone in any Drupal 10 versions?

  • πŸ‡¨πŸ‡¦Canada joseph.olstad

    see my patch here:
    πŸ› [ansi-sql compliant updates] - postgresql/mssql/mysql/sqlite password_policy_update_8304 Needs review

    Blame the major db vendors from not following ansi sql

    My patch works for ALL systems.
    https://www.drupal.org/files/issues/2023-08-14/delete_all_history-331328... β†’

    Password policy history, GONE, in all dbs, no hook crashing.

  • πŸ‡³πŸ‡ΏNew Zealand jweowu

    Thanks joseph. Your patch and πŸ› [ansi-sql compliant updates] - postgresql/mssql/mysql/sqlite password_policy_update_8304 Needs review appears to be about a problem with update 8304 introduced in version 3.2, whereas this issue is about a problem with update 8301 introduced in version 3.1. I'm glad to know of your issue/patch, but from looking at the comments there and the fact that you seemingly had no problems with 3.1, it's not obvious that the two issues are connected.

  • achap πŸ‡¦πŸ‡Ί

    @jweowu this occurred for us on 9.5. I have run into this issue before though and when it occurred it was when I was installing field config programmatically in update hooks, which from glancing at the update hook is what is occurring inside 8302:

      if (!isset($sandbox['progress'])) {
        /** @var \Drupal\Core\Config\ConfigInstallerInterface $configInstaller */
        $configInstaller = \Drupal::service('config.installer');
        $configInstaller->installDefaultConfig('module', 'password_policy');
    
        $sandbox['progress'] = 0;
        $sandbox['max'] = $db_connection->query('SELECT COUNT(uid) FROM {users}')->fetchField();
        $sandbox['current_user'] = -1;
      }
    

    So I think you're right that this might be a core issue... but I can't help with much more than that unfortunately.

    However, what has fixed it for me in the past is just resaving the field storage definition without changing it. That makes the error go away:

      $update_manager = \Drupal::entityDefinitionUpdateManager();
      $field_storage_definition = $update_manager->getFieldStorageDefinition(
        'field_pending_expire_sent',
        'user'
      );
      $update_manager->updateFieldStorageDefinition($field_storage_definition);
    
  • Status changed to Closed: duplicate 8 months ago
  • πŸ‡ΊπŸ‡ΈUnited States Kristen Pol Santa Cruz, CA, USA

    πŸ› [ansi-sql compliant updates] - postgresql/mssql/mysql/sqlite password_policy_update_8304 Needs review has been fixed.

    Closing this as duplicate and creating users here on the other issue.

  • πŸ‡³πŸ‡ΏNew Zealand jweowu

    Hi Kristen. Does that mean that my assessment in #17 was incorrect? The two issues didn't look to me like they were about the same thing.

  • achap πŸ‡¦πŸ‡Ί

    Just to remove any ambiguity I updated the title to reflect that this is an issue with the 8302 update hook not 8301. I think that was entered in error.

    From looking at the committed code in that other issue I don't see how it can be related or fix this issue as the modified code only affects the password_policy_history table while this primarily affects user__field_pending_expire_sent. Unless the conclusion is that the error occurs due to db vendors not following Ansi SQL as suggested in #16? My website that was affected by this is hosted with Acquia if that helps?

  • Status changed to Postponed: needs info 8 months ago
  • πŸ‡ΊπŸ‡ΈUnited States Kristen Pol Santa Cruz, CA, USA

    My mistake. Thanks for clarifying.

    Given this is for 8.x branch, postponing to see if this is relevant for the 4.0.x branch as well. If it is, please move back to "needs review". Thanks.

  • πŸ‡¬πŸ‡§United Kingdom Kionn

    I'm still seeing this issue on the 4.0.x branch. (4.0.0 and 4.0.1).
    (core version: 10.2.3)

    As suggested above, re-running password_policy_update_8302 does seem to make the issue go away.

  • πŸ‡³πŸ‡ΏNew Zealand RoSk0 Wellington

    Re-running password_policy_update_8302() helped to remove entity/field definition mismatch warning on Drupal 10.2.7 , Passoword Policy 4.0.1 and MySQL 8.0.

  • πŸ‡³πŸ‡ΏNew Zealand RoSk0 Wellington

    Disregard previous message please - I got confused.

    When deploying update to production containing Drupal 10.2.7 and Passoword Policy 4.0.1 I had password_policy_update_8302() ran successful . Than was my custom update hook to trigger password_policy_update_8302() again and that failed with Integrity constraint violation: 1062 Duplicate entry '0-0-0-x-default' for key 'user__field_pending_expire_sent.PRIMARY'.

    Now I have this entity field definition mismatch warning on prod , but I'm not sure if that was project code or my mistake with updates...

  • πŸ‡¨πŸ‡¦Canada puregin

    Following up on #5, for Drupal 9.3+ use
    drush eval "\Drupal::service('update.update_hook_registry')->setInstalledVersion('password_policy', 8301);"

Production build 0.71.5 2024