Password policy module is filling in watchdog with errors on cron run

+++ b/password_policy.module
@@ -415,3 +415,12 @@ function password_policy_default_password_policy_alter(&$policies) {
+}
\ No newline at end of file

need a new line

Update hook should be 7201, not 7300. Also yeah, newlines.

Remade the patch in attempt to get it to apply, with the following changes:
- Fixed an indentation error.
- Changed update hook to 7202 instead of 7201, because there is now another patch pending commit that is using 7201. The changes are unrelated so ordering shouldn't matter.

I have not reviewed or tested the functionality provided by this patch; again just trying to get it to apply.

Haven't looked, but I bet this needs to be backported.

Confirmed that users are already removed upon deletion in 7.x-1.x and 6.x-1.x.

Interestingly, 7.x-1.x uses a transaction. erikwebb, do you remember why? You were the person who committed it. Wondering if 7.x-2.x should also use a transaction for some reason.

7.x-1.x code:

/**
 * Implements hook_user_delete().
 */
function password_policy_user_delete($account) {
  $txn = db_transaction();

  // Ensure all deletes occur.
  try {
    db_delete('password_policy_history')
      ->condition('uid', $account->uid)
      ->execute();
    db_delete('password_policy_expiration')
      ->condition('uid', $account->uid)
      ->execute();
    db_delete('password_policy_force_change')
      ->condition('uid', $account->uid)
      ->execute();
  }
  catch (Exception $e) {
    // Something went wrong somewhere, so roll back now.
    $txn->rollback();
    // Log the exception to watchdog.
    watchdog_exception('type', $e);
  }
}

On second review, I think the transaction is just to ensure that either the deletions occur for all three tables or they do not occur. This prevents an inconsistent state where a user's Password Policy data is partially deleted. Since 7.x-2.x-dev currently only has one table from which to delete, no transaction is needed.

Nothing more to do on this issue.