Missing fields in database

I just ran across the issue as well so I created a patch for it.

To answer your additional question @kaelteschutzgebiet, you'd need to add it into the User Profile page yourself via an alter hook or preprocess hook in your theme. This is how we've done it:

/**
 * Implements hook_ENTITY_TYPE_view_alter() for user entities.
 *
 * This function adds the user's API Token to their profile form.
 */
function modulename_user_view_alter(array &$build, UserInterface $account, EntityViewDisplayInterface $display): void {
  // Display API Token for current user.
  if ($account->id() === \Drupal::currentUser()->id()) {
    $token = \Drupal::database()
      ->select(Token::TABLE_NAME, 't')
      ->fields('t', ['public_token'])
      ->condition('user_id', $account->id())
      ->execute()
      ->fetch();

    $build['api_token'] = [
      '#type' => 'item',
      '#title' => t('API Session Token'),
      '#label_attributes' => ['class' => ['label']],
      '#plain_text' => $token?->public_token ?? '',
    ];
  }
}

@codesquatch I wonder why the hook_update is used in place for to add these fields? drush updb created the fields for me.

@MukhtarM It could have been an oversight on the implementing developer, or perhaps an assumption that the update would always file since the module would only be supported on D8/9? Either way, installing the module on fresh D9 and D10 (with patch) site throws the error for me that is in the description of the bug. It was causing a headache in situations where the module is a dependency for a distribution.

Drush updb doesn't update the table.
I have to reinstall module.

I looked at the .install for this module and the problem is that the fields are added in rest_api_access_token_update_8021() but they should also be added to the rest_api_access_token_schema() function. The way Drupal works is if you install the module for the first time Drupal saves the ID of the last update (8021) and only applies updates that are larger than 8021 but will not run any of the previous updates. For fresh installs you need to put the current version of the table in hook_schema(). Currently I don't have time to create a patch but that is the correct way to fix this AFAIK.
The rest_api_access_token_schema() should be something like this:

  $schema['rest_api_access_token'] = [
    'description' => 'Stores access tokens.',
    'fields' => [
      'user_id' => [
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => TRUE,
      ],
      'public_token' => [
        'type' => 'varchar',
        'length' => 128,
        'not null' => TRUE,
      ],
      'secret' => [
        'type' => 'varchar',
        'length' => 128,
        'not null' => TRUE,
      ],
      'created_at' => [
        'description' => 'Created time.',
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => TRUE,
        'default' => 0,
      ],
      'refreshed_at' => [
        'description' => 'Updated time.',
        'type' => 'int',
       'unsigned' => TRUE,
        'not null' => TRUE,
        'default' => 0,
      ],
    ],
    'indexes' => [
      'public_token' => ['public_token'],
      'user_id' => ['user_id'],
    ],
    'primary key' => ['public_token'],
  ];

  return $schema
 

Also I'm pretty sure that the 'default' => time() doesn't work as the author of the module expected. You can't set a dynamic default value. You should use 0 and make sure to add the timestamp via code.

Automatically closed - issue fixed for 2 weeks with no activity.