Problem/Motivation

During a legacy-to-6.x database upgrade using Simple OAuth 6.1.3 and Drupal 11.4.11, simple_oauth_update_8605() fails with:

Update started: simple_oauth_update_8605
SQLSTATE[42S22]: Column not found: 1054
Unknown column 'scopes_target_id' in 'where clause'
Update failed: simple_oauth_update_8605

The update renames oauth2_token__scopes.scopes_target_id to scopes_scope_id before uninstalling the installed legacy entity_reference field definition.

During field uninstallation, Drupal checks whether the field contains data. The installed definition still maps to scopes_target_id, but the physical column has already been renamed, causing the query to fail.

In the observed failed state:

  • The installed token scopes field type remained entity_reference.
  • The table contained scopes_scope_id, but not scopes_target_id.
  • The recorded Simple OAuth schema version remained 8604.

Retrying the unchanged update does not repair this mismatch.

Steps to reproduce

  1. Use a legacy database where update 8605 is pending and the token scopes field still uses the installed entity_reference definition.
  2. Deploy Simple OAuth 6.1.3.
  3. Run drush updatedb.
  4. Observe the missing-column error during update 8605.

This was observed during a local upgrade. Recovery from the resulting partial failure was validated, but reproduction from an untouched legacy database has not yet been independently repeated. Fresh installations using current field definitions are outside the reported scenario.

Proposed resolution

The attached patch removes the premature column rename and lets Drupal uninstall the legacy field using its existing column mapping before installing the replacement field.

It also handles the observed partial failure by restoring scopes_scope_id to scopes_target_id only when:

  • The installed scopes field exists and uses entity_reference.
  • The oauth2_token__scopes table exists.
  • scopes_target_id is absent.
  • scopes_scope_id exists.

The original field uninstall/install logic and token cleanup remain in place. The patch does not manually mark the update complete or implement scope-data migration.

Remaining tasks

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
#2 simple-oauth-8605-restore-legacy-scope-column.patch1.96 KBvtz

Issue fork simple_oauth-3632599

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

vtz created an issue. See original summary.

vtz’s picture

vtz commented
Issue summary: View changes
StatusFileSize
new simple-oauth-8605-restore-legacy-scope-column.patch1.96 KB
sorlov’s picture

sorlov commented

Have the same issue

but I'm wondering why this block is needed at all:

// Rename legacy column from 5.x before uninstalling the field definition.
  $database = \Drupal::database();
  $schema = $database->schema();
  if ($schema->tableExists('oauth2_token__scopes') && $schema->fieldExists('oauth2_token__scopes', 'scopes_target_id')) {
    $spec = [
      'description' => 'The scope id',
      'type' => 'varchar',
      'length' => 255,
      'not null' => FALSE,
    ];
    $schema->changeField('oauth2_token__scopes', 'scopes_target_id', 'scopes_scope_id', $spec);
  }

Looks like patch from #2 solves the mess, made with this block, but not initial issue

bojan_dev made their first commit to this issue’s fork.

bojan_dev opened merge request !249

bojan_dev’s picture

bojan_dev commented

Thanks vtz for the report and the patch.

sorlov, why the rename exists: before the update removes the old scopes field, Drupal checks that field's column for data. Which column it checks depends on the site:

- Most 5.x sites have the column scopes_target_id, and Drupal checks scopes_target_id. The rename breaks this (this issue).
- Some sites, like the one in #3512143: 5.2.x -> 6.0.0 upgrade error, have the column scopes_target_id, but Drupal checks scopes_scope_id. The rename was added to fix these.

So the rename helps the second kind of site and breaks the first. The patch in #2 removes the rename, which fixes the first kind but breaks the second again.

I have introduced a MR that only renames the column when it doesn't match the name Drupal checks. That covers both kinds of site, plus sites where the update already failed once.

Please review.

bojan_dev’s picture

bojan_dev commented
Version: 6.1.3 » 6.1.x-dev
Status: Active » Needs review