Problem/Motivation

Watchdog log have a database exception wrapper for Data too long for column 'subject' at row 1: INSERT INTO "symfony_mailer_log" , this is related to a automated mail that takes the node title and adds some to it. This is the first time we seen this in a very long time with a lot of regular mails so this is probably quite a rare issue.

Steps to reproduce

Sadly I have no good suggestion on how to reproduce this, well except possibly creating a mail with a long subject, in this case it looks to be 310 characters.

Proposed resolution

Before creating a database entry, the data that is to put in should be validated and in cases where it will not fit it should probably be truncated.

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:

Comments

vannergard created an issue. See original summary.

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

svendecabooter’s picture

Status: Active » Fixed

I have added logic to update the length of the subject to 1024 characters maximum, which should cover most use cases.
If the subject is still longer than that, it gets truncated.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

svendecabooter’s picture

Title: To long subject length » Increase subject field length

  • svendecabooter committed 2ded9559 on 1.2.x
    fix: #3605441: increase subject field length
    
    By: svendecabooter
    By:...

Status: Fixed » Closed (fixed)

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

kristofferwiklund’s picture

The update hook is not 100% false proof in Drupal 10. There is a problem then settings via

$field_storage_definition->setSetting('max_length', SymfonyMailerLog::SUBJECT_MAX_LENGTH);

It is updating the settings. But when updating the database in

$entity_definition_update_manager->updateFieldStorageDefinition($field_storage_definition);

The schema for the field is geting an old cache version for the schema.
See:
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

Solving it for me was to run "drush entup" using https://www.drupal.org/project/devel_entity_updates

Or creating my own update hook.

function symfony_mailer_log_update_9103() {
  $database = \Drupal::database();
  $field_name = 'subject';
  $entity_type_id = 'symfony_mailer_log';
  $entity_definition_update = \Drupal::entityDefinitionUpdateManager();
  $table = $entity_type_id;

  // 1. Store data
  $existing_data = [];
  if ($database->schema()->tableExists($table)) {
    $query = $database->select($table, 't');
    $query->addField('t', 'id');
    $query->addField('t', $field_name);
    $existing_data = $query->execute()->fetchAll(\PDO::FETCH_ASSOC);
  }

  // 2. Remove the old field
  $storage_definition = BaseFieldDefinition::create('string')
    ->setName($field_name)
    ->setTargetEntityTypeId($entity_type_id);
  $entity_definition_update->uninstallFieldStorageDefinition($storage_definition);

  // 3. Add the new field.
  $storage_definition = BaseFieldDefinition::create('string')
    ->setLabel(t('Subject'))
    ->setDescription(t('The email subject.'))
    ->setSetting('max_length', SymfonyMailerLog::SUBJECT_MAX_LENGTH)
    ->setDisplayOptions('view', [
      'label' => 'above',
      'type' => 'string',
    ])
    ->setDisplayConfigurable('view', TRUE);
  $entity_definition_update->installFieldStorageDefinition($field_name, $entity_type_id, 'symfony_mailer_log', $storage_definition);

  // 4. Restore data.
  foreach ($existing_data as $row) {
    $database->update($table)
      ->fields([$field_name => $row[$field_name]])
      ->condition('id', $row['id'])
      ->execute();
  }
}