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

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.

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

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

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?

> 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?

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.

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.

@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);

🐛 [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.

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.

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?

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.

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.

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.