Base table or view not found

Created on 12 August 2022, almost 2 years ago
Updated 7 June 2024, 21 days ago

Problem/Motivation

Hi,
After I pushed from working local dev environment to GIT, pulled in production and run composer install, drush cr and drush cim -y, drush updatedb, I got this error when accessing /user/register
also dbupdates does not go without failing.
On local dev I do not have this error, and it should be identical with the production.

The dbupdate error is:

externalauth module
Update #8102
Failed: Drupal\Core\Database\SchemaObjectDoesNotExistException: Cannot add unique key 'authname_provider' to table 'authmap': table doesn't exist. in Drupal\mysql\Driver\Database\mysql\Schema->addUniqueKey() (line 538 of /var/www/html/site/web/core/modules/mysql/src/Driver/Database/mysql/Schema.php).

the server log errors are

" at /var/www/html/site/web/core/modules/mysql/src/Driver/Database/mysql/ExceptionHandler.php line 53" while reading response header from upstream, client: 172.21.24.220, server: site.com, request: "GET /user/register HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php8.1-fpm.sock:", host: "site.com", referrer: "https://site.com/user/login"
2022/08/12 07:32:57 [error] 1089#1089: *465496 FastCGI sent in stderr: "PHP message: Uncaught PHP Exception Drupal\Core\Database\DatabaseExceptionWrapper: "SQLSTATE[42S02]: Base table or view not found: 1146 Table 'site.authmap' doesn't exist: SELECT "am"."provider" AS "provider", "am"."authname" AS "authname"
FROM
"authmap" "am"
WHERE "uid" = :db_condition_placeholder_0
ORDER BY "provider" ASC; Array
(
    [:db_condition_placeholder_0] => 0
)
" at /var/www/html/site/web/core/modules/mysql/src/Driver/Database/mysql/ExceptionHandler.php line 53" while reading response header from upstream, client: 172.21.24.220, server: site.com, request: "GET /user/register HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php8.1-fpm.sock:", host: "site.com", referrer: "https://site.com/user/login"

Steps to reproduce

EDIT: before this problem, running drush updatedb after drush cim -y gives:
Message: Schema information for module /externalauth/ was missing from the database.
You should manually review the module updates and your database to check if
any updates have been skipped up to, and including,
/externalauth_update_8103()

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

💬 Support request
Status

Active

Version

2.0

Component

Code

Created by

🇫🇮Finland Youcanlearnit

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.

  • 🇨🇦Canada colan Toronto 🇨🇦

    This is still a problem in 2.0.3. Yes, this is supposed to get created when you run drush config-import, assuming that you've added the file to core.extension.yaml.

    I'm not sure why, but it didn't seem to actually be installing. We should see something like this:

    [notice] Synchronized extensions: install externalauth.

    But it didn't happen in my case, but that's also weird because the module seemed to be installed as I could configure it and there's a hook_schema implementation.

    Maybe this is related to 🐛 hook_install() is invoked before the module's default config is installed during config import Needs work or #2451365: ConfigInstaller has the source storage injected by config importer and module installer but it is done incorrectly ?

  • 🇨🇦Canada colan Toronto 🇨🇦

    On further investigation, this was caused by lando pull moving me to the wrong branch. This command seems to switch to master for no good reason; all it needs to do is import a remote DB. So I was on the wrong branch. When I switched to the correct branch before running drush config-import, the authmap table actually got created. Sorry for the noise.

  • We are having the same issue and we are not using the wrong branch. We just used imported the database from another environment in our dev environment so we did not had to do cim as well. So not sure what else we should try. This is the error when we tried to delete the module,

    In ExceptionHandler.php line 56:

    SQLSTATE[42S02]: Base table or view not found: 1146 Table 'dbname.auth
    map' doesn't exist: DELETE FROM "authmap"
    WHERE "provider" = :db_condition_placeholder_0; Array
    (
    [:db_condition_placeholder_0] => open_connect.hq
    )

    In StatementWrapperIterator.php line 111:

    SQLSTATE[42S02]: Base table or view not found: 1146 Table 'dbname.auth
    map' doesn't exist

  • 🇪🇸Spain rteijeiro

    Same here after upgrading drupal core and openid_connect modules:

    - Drupal 10.2.4
    - OpenID Connect / OAuth client 3.0.0-alpha3
    - OpenID Connect Microsoft Azure Active Directory client 2.0.0-beta7

    >  [error]  SQLSTATE[42S02]: Base table or view not found: 1146 Table 'db.authmap' doesn't exist: SELECT 1 AS "expression"
    > FROM
    > "authmap" "authmap"
    > WHERE ("uid" = :db_condition_placeholder_0) AND ("provider" = :db_condition_placeholder_1); Array
    > (
    >     [:db_condition_placeholder_0] => 13
    >     [:db_condition_placeholder_1] => openid_connect.windows_aad
    > )
    >  
    >  [error]  Update failed: openid_connect_update_8204 
    
  • As workaround I create a custom module and copy schema from externalauth module then enable this custom module manually fixed my issue

  • 🇧🇪Belgium svendecabooter Gent

    Probably related to 🐛 Update to OpenID Connect Module 2.0 Fails Due to Missing 'authmap' Table Required by Externalauth Dependency Active ?

    It seems the openid_connect module activates the externalauth module within an update hook openid_connect_update_8203() and then migrates over its own authmap data to the externalauth one openid_connect_update_8204().

    I'm not sure why upon installation of the externalauth module, the {authmap} table would not be created. It is defined via hook_schema(), and has been there from the start of the module.

    I'm really clueless as to why this would happen. Seems it only occurs in combination with the openid_connect module then?
    Something must go wrong with installation of the module then, or the schema definition might not have been updated yet by the time openid_connect_update_8204() gets called (some caching issue?)

Production build 0.69.0 2024