🇺🇸United States @glassb

I tested MR !17 on a site running 10.1.8 with content moderation, but I found that duplicate profiles were still being created. After some debugging, it looks like it is making it to

if ($profile_exists) {
      $this->context->buildViolation($constraint->errorMessage)
        ->atPath('uid')
        ->addViolation();
    }

and $profile_exists does evaluate as true when expected. I'm not familiar with Symfony constraints, but it seems like once the violation is raised it should prevent the submission. I tried looking into it, but it looks correct as far as I can tell.

For now, #2 patch does seem to work for me.

I've tested on a local development site and can confirm that MR 1 fixes the issue.

pstewart → credited glassb → .

I was able to apply MR87 to one of our test sites and everything seems to be working as expected. I can confirm the wid column was successfully changed from int to bigint in the database and all of the data seems to have been copied over correctly.

I also tested how the table lock would handle other traffic during the update by:

1. Adding a 5 minute delay after the schema lock with $this->connection->queryDirect("WAITFOR DELAY '00:05:00'");.
2. Running drush updatedb.
3. Performing operations on the site that would generate logs.
4. Running a select query in SSMS.
5. Checking resulting logs after updates were complete.

I found that while the database updates were running, the site would continually load on any requests that would generate logs. Afterwards, all of the logs generated during that update were shown in the new table. I was also unable to query the table during the updates. This suggests to me that the table lock is functioning as expected and preventing any inserts until after the update is complete.

Everything seems to be functioning correctly so I believe this is ready to be marked RTBC. Hopefully we can get a release candidate out soon. Thanks to everyone who worked on this issue!