[Regression] Pattern not being respected

I have a similar problem.

I've imported content via cron and the pattern is not respected. After the cron job is done, the patterns are correct. It appears that a task is being run that is executing the correct pattern.

I don't have this problem when I create a new node manually.

@bhoque
Is there a hook or similar that you do after saving a node? This may be preventing autoentity_label from setting the correct title.

Same problem here. But when I open the node to edit and save again, the node title is generated properly.
As a workaround I now changed the settings to "Create label before first save".

Having the same issue as #4

We're seeing the same issue. Our pattern uses a single token that points to a text field on the same entity. That field allows some minimal formatting, but the generated labels are as described above (e.g. %AutoEntityLabel: 7a075eef-dde7-4c04-8f99-8f6a3f6e6177%) whether or not the field values contains formatting.

Re-saving the node corrects the generated label. Switching to the new 'Create label before first save' setting also works in our case.

No time to debug right now, but my assumption is this stems from changes in #3076302: Set Label runs two times on node creation.

Have the same issue. I'm using this in conjunction with 'Token OR' pattern and a node reference field 'Authors' set to 'Create referenced entities if they don't already exist'.

So if someone inputs a profile node in 'Authors' that doesn't exist, the entity is created, and for the title it first it looks if the name field is populated, if not it uses the auto generated title from 'Create referenced entities' and if neither of those work then it fills it with 'Unnamed profile' as a fallback.

If someone creates a profile node manually it takes the title from 'field_profile_name' which is a mandatory field.

My token for auto_entity label is:

[node:field_profile_name|node:title|"Unnamed profile"]

Not sure how to configure this to get it to work - had to roll back to 8.x-3.2.

I have the same problem and tried to debug this. In function auto_entitylabel_entity_insert() the $decorated_entity->autoLabelNeeded() part always returns false, thus the placeholder generated during pre-save never gets replaced with the correct token-based value with the configuration "Automatically generate the label if the label field is left empty" and "Create label after first save":

  public function autoLabelNeeded() {
    $not_applied = empty($this->autoLabelApplied); // --> true
    $required = $this->hasAutoLabel(); // --> false
    $optional = $this->hasOptionalAutoLabel() // --> false
      && empty($this->entity->label()); // --> false

    return $not_applied && ($required || $optional); // true && (false || false) --> false
  }

This still exists in 3.4 and as it can break production sites chaning priority to Major (but not critical because in my case there's a workaround by changing new content behavior to "Create label before first save" works).

Marking as regression as it breaks existing behavoir.

Confirming that the work around fixes this bug on our urban.org production environment where we use this module to generate a node label for our Author nodes based on a `field_name`.

This is just a theory:
This might not be a bug in this module, but instead an edge case that causes a bug in Drupal core.
https://www.drupal.org/project/drupal/issues/3181946

For me, applying my drupal/core patch from https://git.drupalcode.org/project/drupal/-/merge_requests/12229.patch fixes this issue.

I'm wondering if folks who are bumping into this issue here have more than one database connection defined in their settings? If so, maybe try out that patch and see if it fixes this issue.

The problem appears to be that that auto_entitylabel, when using the "Create label after first save" option, is using drupal_register_shutdown_function('_auto_entitylabel_post_insert', $entity); (auto_entitylabel_entity_insert). Was it using a shutdown function before this regression appeared?

What is being discussed on #3181946: ReplicaKillSwitch unnecessarily starts a session on each request is that SqlContentEntityStorage::save calls \Drupal::service('database.replica_kill_switch')->trigger(); and this will throw an exception when the session is no longer active -- which will be the case in a shutdown function. In my experience, it's only revealed as a problem if your Drupal settings have more than one database connection. Once the Exception is thrown, the database transaction that is normally wrapped around an entity save is then rolled-back and the second auto_entitylabel save is never committed to the database.