Fatal error when deleting a user account, caused by missing DB table.

[richardlampitt]

Description of the bug

Attempting to cancel a user account results in a fatal error, caused by a missing profile database table.

The calling function is in the entity_plus module, but I suspect that the ultimate cause is within the profile module, as profile is where this entity is defined, and thus I assume responsible for all database stuff.

Here's the error message:

An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /batch?id=311111&op=do_nojs&op=do StatusText: Service unavailable (with message) ResponseText: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'script-revolution_backdrop.profile' doesn't exist: SELECT `base`.`pid` AS `pid`, `base`.`type` AS `type`, `base`.`uid` AS `uid`, `base`.`label` AS `label`, `base`.`created` AS `created`, `base`.`changed` AS `changed` FROM {profile} `base` WHERE (`base`.`uid` = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => 311110 ) in EntityPlusController->query() (line 215 of C:\wamp64\www\_backdrop\sr-backdrop.local\httpdocs\modules\contrib\entity_plus\includes\entity_plus.controller.inc).

Steps To Reproduce

With entity_plus enabled, attempt to delete a user.

Actual behavior

Fatal error, as above. The user remains intact.

Expected behavior

User is deleted without errors.

Additional information

Add any other information that could help, such as:

• Backdrop CMS version: 1.31
• Web server and its version: apache 2.4.54
• PHP version: 8.1+ (tested with 8.1 and 8.3)
• Database sever (MySQL or MariaDB?) and its version: MariaDB Version: 10.11.11
• Operating System and its version: Windows NT 10.0 build 19045 (Windows 10) AMD64

Because the calling function is in a different module, I've not yet had the opportunity to fully investigate and trace the ultimate issue yet.

[argiepiano]

Hey, @richardlampitt I haven't tried to reproduce yet. I wanted to mention that the error you got is produced when any AJAX batch operation fails, and doesn't really tell us anything about the error that actually produced that failure, so it's impossible to troubleshoot the cause.

Please open your database error log under Reports, and look for errors that happened right before that one.

[richardlampitt]

Sure thing! Give me a moment.

[richardlampitt]

The only error that's coming up is the PDO error for the missing database table, just without the AJAX wrapper:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'script-revolution_backdrop.profile' doesn't exist: SELECT `base`.`pid` AS `pid`, `base`.`type` AS `type`, `base`.`uid` AS `uid`, `base`.`label` AS `label`, `base`.`created` AS `created`, `base`.`changed` AS `changed` FROM {profile} `base` WHERE (`base`.`uid` = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => 311110 ) in EntityPlusController->query() (line 215 of C:\wamp64\www_backdrop\sr-backdrop.local\httpdocs\modules\contrib\entity_plus\includes\entity_plus.controller.inc).

[richardlampitt]

Investigating further, it seems that during the Drupal 7 → Backdrop migration, the profile_schema function hasn't been triggered, so the database table hasn't been created.

I'm going to create this table manually as a workaround to get the delete operation usable.

Additional info: disabling the user account doesn't trigger this error. I imagine this is the only account cancellation that's causing problems because it's trying to delete stuff.

[richardlampitt]

If anyone encounters this issue henceforth, here's the SQL I used to create the table and fix the problem:

CREATE TABLE `profile` (
  `pid`       SERIAL         NOT NULL                  COMMENT 'Primary Key: Unique profile item ID.' , 
  `type`      VARCHAR(32)    NOT NULL   DEFAULT ''     COMMENT 'The {profile_type}.type of this profile.' , 
  `uid`       INT UNSIGNED   NULL       DEFAULT NULL   COMMENT 'The {users}.uid of the associated user.' , 
  `label`     VARCHAR(255)   NOT NULL   DEFAULT ''     COMMENT 'A human-readable label for this profile.' , 
  `created`   INT            NULL                      COMMENT 'The Unix timestamp when the profile was created.' , 
  `changed`   INT            NULL                      COMMENT 'The Unix timestamp when the profile was most recently saved.' , 
  PRIMARY KEY (`pid`)
) ENGINE = MyISAM; 

[argiepiano]

Investigating further, it seems that during the Drupal 7 → Backdrop migration, the profile_schema function hasn't been triggered, so the database table hasn't been created.

In fact, this is normal. The profile table must have existed in your Drupal 7 site, and so, if the module was enabled in your Drupal site, the upgrade will never create tables again when during the upgrade, since the tables already must have existed in your D7 site. My only guess here is that that profile table was deleted by mistake.

Further: hook_schema only creates tables when a module that was fully disabled and uninstalled is installed and fully enabled. When you upgrade a site from D7 with an enabled module, that module is seen as enabled during the Backdrop upgrade, and so Backdrop will not attempt to create the tables again. You'd get a fatal error if it tried to do that.

[richardlampitt]

Checking the existing database, it seems that there's no profile table, but a profile_field and a profile_value table instead?

Further: hook_schema only creates tables when a module is installed and enabled for the first time. When you upgrade a site from D7 with an enabled module, that module is seen as enabled during the Backdrop upgrade, and so Backdrop will not attempt to create the tables again. You'd get a fatal error if it tried to do that.

Grand, thank you for the elaboration!

Would it make sense to add a check that the database table exists at some point, either on migration or on delete attempt?

[bugfolder]

Rather than adding a check for every delete attempt, we should try to catch this at upgrade time; and to do that, see if we can figure out how your table ended up deleted at upgrade time.

Do you recall: did you have the D7 Profile2 module installed and left installed when you attempted the upgrade? Or had you disabled or unintalled it before the upgrade?

[richardlampitt]

Rather than adding a check for every delete attempt, we should try to catch this at upgrade time; and to do that, see if we can figure out how your table ended up deleted at upgrade time.

Do you recall: did you have the D7 Profile2 module installed and left installed when you attempted the upgrade? Or had you disabled or unintalled it before the upgrade?

Profile2 was disabled and the codebase removed before the upgrade. We didn't explicitly uninstall anything as that caused data loss.