Problem/Motivation

#253157: Add "Translate own content" permission, rename "Translate content" to "Translate all content" was committed in earlier versions of Drupal 8 which allowed users to translate their own content. However, this feature was later removed from the core and it made https://www.drupal.org/node/1776752 obsolete.

Nowadays, multilingual community sites still have a requirement to allow users to translate their own content.

Proposed resolution

Based on @Berdir's feedback:

Options are:

• New permissions: "translate own entities", "translate own {entity_type}", "translate own {bundle} {entity_type}"
• Single global permission: "allow translating content that the user can edit"

Remaining tasks

Discuss.

User interface changes

API changes

Data model changes

Problem/Motivation

Drupal 9 will release with Symfony 4.4, see #3009219: Update Symfony to 4.4 in Drupal 9.0. In order to be able to do that, we should make Drupal 8 compatible with Symfony 4.4 first as much as possible. We cannot allow Symfony 4.4 to be installed from a simple composer update command, as current ways to install Drupal with composer would not protect production sites from switching to Symfony 4.4 which is unintended. That also means that until there is a Drupal 9 branch, there will be no easy way to test contrib with Symfony 4.4.

Proposed resolution

1. Resolve and commit the remaining issues needed to make Symfony 4 pass tests.
2. Provide a script or instructions on how to adjust the various composer.json files for those adventurous souls who wish to try it with contrib, but it should not happen by default on a simple update.

Focus on Symfony 4.4 here. All Symfony 5 releated work is in #3055180: [META] Make Drupal 8 work with Symfony 5 (along with Symfony 3 and 4).

Remaining tasks

The following outstanding issues must be resolved to make the tests pass:

• A chromedriver test fail that is still being debugged.

User interface changes

None.

API changes

Symfony 4.4 API will be supported.

Data model changes

None

Release notes snippet

Drupal now supports Symfony 4.4.

If Twig Debug is active and I have a Group By field in my view, if I have a label, it shows the Twig Debug output. If I remove the label, it displays as expected.

Without a label

With a label

------

I feel like I've seen another issue related to labels and Twig Debug output being exposed, but I can't find it.

Problem/Motivation

A number of users have become confused around the datetime element's format attributes #date_date_format and #date_time_format.

If you use the HTML5 form elements (which are only supported in some browsers, others make them behave like text fields), then the date/time formats *have* to be the HTML5 flavors ('Y-m-d' and 'H:i:s'). And per Datetime::getInfo(), they default to the HTML5 inputs when not specified.

Part of the problem comes from the docs being in a weird place for this form element.

Proposed resolution

Possible solutions include:

1. Improve the docblocks and/or move some of the information around, perhaps much on Datetime::processDatetime() should be moved to the top level comment on the class (and some of that may not be accurate in Drupal 8 anymore).
2. Trigger a notice when custom formats are specified with the HTML5 elements.
3. If a custom format is specified, then force the element to 'text' (maintainer is not keen on this, and it has probably has BC consequences).

Remaining tasks

Discuss, agree, code.

User interface changes

None

API changes

TBD

Data model changes

None.

Original Summary

We are getting error - Error : "The date is invalid. Please enter a date in the format 2017-05-03 12:57:23". even if we provided expected format in '#date_date_format'& '#date_time_format' in our custom form field - datetime as below code.

$form['datetime'] = [
  '#type' => 'datetime',
  '#size' => 20,
  '#date_date_format' => 'd/m/Y',
  '#date_time_format' => 'H:m',
];

Value Provided on Form Submission : "03/05/2017 12:57:23"

Expected format : "d/m/Y" but Drupal 8 - DateTime supports only "Y-m-d".

I guess, Drupal 8 follow the HTML5 () default date format. Please skip this validation if user provided their own date formats. Please help us to resolve this.

--
Thanks
Vignesh.R

Problem/Motivation

I have a lot of custom entities passed for processing (deletition) in a queue.
Whenever a single worker processes the items, all is OK.
Whenever I enable a second one, the mentioned exception starts to happen every so often.

 [error]  Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: INSERT INTO {cache_bootstrap} (cid, expire, created, tags, checksum, data, serialized) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6) ON DUPLICATE KEY UPDATE cid = VALUES(cid), expire = VALUES(expire), created = VALUES(created), tags = VALUES(tags), checksum = VALUES(checksum), data = VALUES(data), serialized = VALUES(serialized); Array
(
    [:db_insert_placeholder_0] => last_write_timestamp_cache_bootstrap
    [:db_insert_placeholder_1] => -1
    [:db_insert_placeholder_2] => 1563527591.201
    [:db_insert_placeholder_3] => 
    [:db_insert_placeholder_4] => 0
    [:db_insert_placeholder_5] => d:1563527591.2019999;
    [:db_insert_placeholder_6] => 1
)
 in Drupal\Core\Cache\ChainedFastBackend->markAsOutdated() (line 306 of /var/www/vdk-multisite/docroot/core/lib/Drupal/Core/Cache/ChainedFastBackend.php).

Note that if I replace cache bootstrap with alternative cache implementation (memcache / redis) all get's OK right away.

This is reproducible on DrupalVM without any customization on the database configs.

Proposed resolution

Whenever there is concurrency the database cache can not handle concurrent updates on the same key very often.

Why not consider to catch the exception re-read it from DB, as someone is actually writing at the moment. If that timestamp is (bigger than the one we have, we can skip the write operation.

Otherwise retry the write operation and then fail as it currently does. Hopefully in a high write scenarios, this should alleviate the pain on the row lock for the key on MySQL level.

Remaining tasks

Discussions, Patch, Reviews etc.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None (bug-fix).

Original summary

On a custom entity we are seeing several database deadlock errors like following. Our module like others has no control on how Drupal issues database transactions or rolls them back when deadlocks are encountered.

So the question is are these deadlocks on cache_bootstrap benign?

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: INSERT INTO
{cache_bootstrap}
(cid, expire, created, tags, checksum, data, serialized) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6) ON DUPLICATE KEY UPDATE cid = VALUES(cid), expire = VALUES(expire), created = VALUES(created), tags = VALUES(tags), checksum = VALUES(checksum), data = VALUES(data), serialized = VALUES(serialized); Array ( [:db_insert_placeholder_0] => last_write_timestamp_cache_bootstrap [:db_insert_placeholder_1] => 1 [:db_insert_placeholder_2] => 1552019948.235 [:db_insert_placeholder_3] => [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => d:1552019948.236; [:db_insert_placeholder_6] => 1 ) in Drupal\Core\Cache\ChainedFastBackend>markAsOutdated() (line 306 of /var/www/html/core/lib/Drupal/Core/Cache/ChainedFastBackend.php).

Problem/Motivation

Currently, User X can request a new password an infinite amount of times. This can be confirmed by the logs at admin/reports/dblog.
Update 8/15/13: The issue is still in the Drupal8 download as I have tested.

Proposed resolution

Create flood event and enforce it.
Create/modify tests in order so that this patch can pass. Since the flood protection takes action after a while the user will not be able to login after too many tries, and this the way it should work. The tests should let this pass.

Remaining tasks

Addressing concerns of @David_Rothstein in #73

I was going to say that looked like a good change, but then it occurred to me: Because the flood control is by IP address, we actually have no idea how many times the current user tried to reset their password recently (it could be zero).

Which actually means this: If many users at an organization all share the same IP address, then a malicious user at the same IP address (let's say a disgruntled employee situation) could trigger the flood control deliberately by continually requesting multiple passwords for their own account. Since there were no password reset requests for other accounts, those users will not have any login links in their e-mail to click on, nor will they be able to generate them. So they will be completely locked out of the site (assuming the attacker flooded the login form too), and the only way to get back in is to wait for someone with technical knowledge to go onto the server and fix things.

I have to ask, isn't the above scenario actually more dangerous than the simple "spam" scenario the patch is trying to protect against?

See one opinion on this tradeoff in #127 - tl;dr the benefit outweighs the risk (which is a bit of an edge-case).

User interface changes

TBD

API changes

TBD

Original report by Traverus

Currently, User X can request a new password an infinite amount of times. There should be a flood event created and enforced. I'll include the code that I used to implement my own solution to help get toward a patch for the problem.

As a for instance Bob doesn't like Alice, so he resets Alice's password 1230875109 times. This makes Alice upset because she has an equal amount of e-mails in her inbox.

Thanks!

function xyz_user_pass_form_validate($form, $form_state){
  if(!flood_is_allowed('request new password', 1, 86400, $form_state['values']['name'])){
    form_set_error('name', 'Reset password limit exceeded.  Please contact technical support for further assistance.');
	flood_register_event('request new password', 86400, $form_state['values']['name']);
  } else {
    flood_register_event('request new password', 86400, $form_state['values']['name']);
  }
}

hook_form_user_pass_alter($form){
  array_unshift($form['#validate'], 'xyz_user_pass_form_validate');
}

Documentation for ConfigFactoryOverrideInterface::loadOverrides requires an array argument, but api does not typehint.

via

interface ConfigFactoryOverrideInterface {

  /**
   * Returns config overrides.
   *
   * @param array $names
   *   A list of configuration names that are being loaded.
   *
   * @return array
   *   An array keyed by configuration name of override data. Override data
   *   contains a nested array structure of overrides.
   */
  public function loadOverrides($names);

TL;DR: dev site initially installed fine, then after a little development, started getting integrity violations on the router table each time it was rebuilt, and then found I was even getting them on a brand new install on a clean DB. I switched from MariaDB to an older MySQL server install on same machine - all the problems went away and I was able to restore from my backup.

---

I had a working site and suddenly found that drush cr failed with errors along the lines of:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'system.cron_settings' for key 'PRIMARY'

for an SQL insert into the router table. There was indeed an existing row with that name, but deleting the row doesn't help as it merely complains about another record in turn until I've removed the entire table. drush cr will then finish, but of course I have no routing…

Restoring my latest DB backup didn't help, along with truncating cache* tables manually etc.

I noticed the router table only had ~90 rows and on checking earlier backups (I usually take them at every few hours, minimum) it had had around 630 before. The weird thing was that backup was several generations old - well over a day, and I had definitely cleared the cache multiple times since then without seeing any errors, and added/removed various modules.

So I tried bringing that larger table into the most recent copy of the database, that restored my homepage and access for anonymous users, but then I started getting an error about a missing book.admin route as soon as I logged in (the book module is enabled, and I couldn't find a way to disable it cleanly in Drush, or access any of the admin pages).

At this point, I wondered if it would be easier to export all my configuration with `drush cex` (it's a new site so there's no important data, and anyway I have DB backups), commit that to Git, wipe the database completely, rerun the installation script and reimport the config.

So I completely erased the DB, and deleted all the non-core modules from web/modules/contrib.

I ran the installer on a completely empty DB, and the existing composer managed codebase (with modules removed) and it then failed with:

Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'system.401' for key 'PRIMARY': INSERT INTO {router} 

(looking at the DB it's written 63 routes to the router table, most of them system.*, as well as the front page and so on.)

I've actually restored the composer.json to the default version for drupal-composer/drupal-project, and run composer update, and also done a composer dump-autoload (it says 558 classes)

Any suggestions what I could try next? Is there anywhere else in the file system I need to cleanup?

My first thought was the t one of the modules I used and later uninstalled somehow trashed the DB.

There was also a brief power cut last night, and this happened after that, but I think I can rule it out as I mentioned I've been restoring backups from before then and when the router table "wasn't right", and MySQL had no issues on startup this morning.

Drupal 8.7.4 (tested with both PHP 7.2 and 7.3, running on Laravel Valet on macOS)

Here are the modules I've been using (I did also install and uninstall a couple, such as inline_entity_form)

"drupal-composer/drupal-scaffold": "^2.5",
"drupal/auto_entitylabel": "^2.1",
"drupal/coffee": "^1.0",
"drupal/config_ignore": "^2.1",
"drupal/config_override_warn": "^1.2",
"drupal/console": "^1.0.2",
"drupal/content_access": "^1.0",
"drupal/core": "^8.7.0",
"drupal/devel": "^2.1",
"drupal/double_field": "^3.3",
"drupal/environment_indicator": "^3.6",
"drupal/field_group": "^3.0",
"drupal/field_permissions": "^1.0",
"drupal/field_tools": "^1.0",
"drupal/flag": "^4.0",
"drupal/ga_login": "^1.0",
"drupal/hms_field": "1.x-dev",
"drupal/masquerade": "^2.0",
"drupal/metatag": "^1.8",
"drupal/pathauto": "^1.4",
"drupal/required_by_role": "^1.0",
"drupal/role_delegation": "^1.0",
"drupal/seo_checklist": "^4.1",
"drupal/spambot": "^1.0",
"drupal/stringoverrides": "1.x-dev",
"drupal/structure_sync": "^1.16",
"drupal/tfa": "^1.0",
"drupal/token": "^1.5",
"drupal/toolbar_menu": "^2.1",
"drupal/unique_field_ajax": "^1.2",
"drupal/views_secondary_row": "^1.0",

Problem/Motivation

Issues we're trying to solve

• core: 8.x in an info file is restrictive
• we invented our own dependency syntax that is overly complex because of the optional core major version
• we want to move away from having the major version in the module version (e.g. 8.x-1.x » 1.0.0)
• we want to move core away from version: VERSION so we can do subtree splitting
• we want contrib modules to be able to declare their composer dependencies - e.g my module 1.3 needs symfony/yaml 4.0
• as a bonus, themes could rely on modules

@sun suggested this in #1936886-21: Rename $module.info.yml into extension.yml

Proposed resolution

use composer.json for

• discovery of themes/modules/profiles/engines
• dependency declaration
• version numbering

Deprecate the dependencies, type and version keys in info.yml files

Remaining tasks

Wind back to the scope of comment #39

User interface changes

API changes

Data model changes

Problem/Motivation

As a spin-off from #3037228: Add more test coverage to Help Topics, we would like to ensure that all topics written for the new Help Topics Core module have proper syntax, for all non-test modules in Core.

Proposed resolution

Add checks for the following syntax issues:
- Meta tag for the title (label) must be present (help_topic:label)
- Topic must be either top-level or related to a top-level topic
- HTML syntax is valid (without the Twig stuff and meta tags)
- All text in the topic is wrapped in Twig translation tags.
- No H1 tag
- If there is an H3, there should be an H2, and so on
- The topics can be viewed at their URL

Things we are not explicitly testing in this test:
- The discovery process already reads label, related, and top-level from the meta tags, so this test can use the result instead of verifying the meta tags itself.
- The discovery process throws an exception if any other meta tags are encountered
- We are only testing Core. It would be desirable to also test Contrib but I'm not sure how we could accomplish this... but as a note, if a particular contrib module is in the file system when you run these tests, it will be discovered and tested.

Remaining tasks

Add the checks.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Added new checks to ensure Help Topic Twig files have proper syntax.

ISSUE CREDIT

This was spun off from #3037228: Add more test coverage to Help Topics and a patch there was the starting point:
https://www.drupal.org/files/issues/2019-07-08/core-add-more-test-covera...

Please credit scott_euser on this issue, who created that patch, and jhodgdon, who reviewed it.

Problem/Motivation

The link manager service allows to set a specific link domain by calling the method 'ConfigurableLinkManagerInterface::setLinkDomain($domain)'.

On the other hand, the type link manager manages a cache of type links present in the system. Each type link is identified by a URI that is based on the link domain setted at the moment that the cache is written.

If the link domain name changes by calling setLinkDomain, the link type cache remains as it was.

Steps to reproduce

1. fresh install of 8.5-dev Drupal with standard profile
2. enable the HAL module. Will ask to enable serialization as well by dependency. Also enable the 'rest' module needed as a new dependency, see [#1155816]
3. download and enable the devel module
4. try at /devel/php this working-well PHP snippet, that serializes and un-serializes a node:
   

   $node = \Drupal\node\Entity\Node::create([
     'type' => 'page',
     'title' => 'Test node',
   ]);
   
   $serialized_node = \Drupal::service('serializer')->serialize($node, 'hal_json');
   
   $new_node = \Drupal::service('serializer')->deserialize($serialized_node, 'Drupal\node\Entity\Node', 'hal_json');
   echo $new_node->get('title')->getString();
   

5. at the same place, replace previous test code by this one that does the same but changing the link domain, it causes a "Type http://example.com/rest/type/node/page does not correspond to an entity on this site." exception:
   

   \Drupal::service('hal.link_manager')->setLinkDomain('http://example.com');
   
   $node = \Drupal\node\Entity\Node::create([
     'type' => 'page',
     'title' => 'Test node',
   ]);
   
   $serialized_node = \Drupal::service('serializer')->serialize($node, 'hal_json');
   
   $new_node = \Drupal::service('serializer')->deserialize($serialized_node, 'Drupal\node\Entity\Node', 'hal_json');
   echo $new_node->get('title')->getString();
   
   \Drupal::service('hal.link_manager')->setLinkDomain('');
   

Rebuilding the cache and retrying the last step will work, because the type links cache is write again with the setted link domain.

Note that it only affects the de-serialization process, in serialization the last setted link domain is always used.

Proposed resolution

1. Clear the type links cache when a new link domain is set.
2. Write the type link by absolute URI (with no domain) and add it in getters.

Remaining tasks

Notify about it in docs (until solved) to module developers that makes usage of serialization. Currently, any module that changes the link domain should clear the "hal:links:types" cache to avoid this issue and also prevent malfunctioning of any other module that works with HAL, since type links cache remains with unexpected URI.

API changes

Depending on how it is solved, the API could be affected.

Problem/Motivation

Some of the test topics, test modules, and tests in Help Topics are relying on production help topics, or linking to production help topics. This could cause problems if one of the production help topics changes, gets deleted, etc.

Proposed resolution

Make it so the tests and test modules for Help Topics are completely decoupled from production topics.

Remaining tasks

Make a patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

The Symfony 3 will be end of life in 2021. This means we need to be ready to move to Symfony 4.4 before then. This is a major trigger to releasing Drupal 9 in 2020. See #3007300: [META] Release Drupal 9 on June 3 2020. While Symfony 5 will be available by the time Drupal 9 comes around, it will be the first release to only receive security fixes for 8 months (https://symfony.com/blog/symfony-maintenance-changes-for-standard-releases) so given that Drupal core is supported for 12 months, Drupal 9 cannot adopt Symfony 5.

Proposed resolution

Update to Symfony 4.4.

Remaining tasks

1. First need to be compatible with Symfony 4.4. See #2976394: Allow Symfony 4.4 to be installed in Drupal 8 which is a testing issue to find Symfony 4 compatibility issues in Drupal 8 itself.
2. Once that works, we need a patch to actually update to Symfony 4.4. (Part of #2976394: Allow Symfony 4.4 to be installed in Drupal 8 has that patch, but we would need a separate issue likely to commit to Drupal 9).

User interface changes

None.

API changes

None directly in this issue.

Data model changes

None directly in this issue.

Acquia performed a series of user tests around Layout Builder (I'm still working out how to make as much of those results as we can generally available to the community). But universally, this was a huge barrier to folks.

Excerpts from the findings:

Users had difficulty navigating among the many block types available to them. It was unclear how the categories were constructed. One user wanted meta-data versus media types (etc), but saw these types mixed within categories. Users wanted to sort (e.g., alphabetically, chronologically) among block types rather than use the categories provided.

Additionally, this sidebar is basically a never-ending barf of "Drupally words" to an audience of people (content authors) who shouldn't need to know/care that Drupal (or views or blocks or CTools or whatever) is what's powering the interface. Another key quote from the findings:

Users shouldn’t need to speak Drupal to use Drupal!

Indeed. ;)

#2977587: Improve block listing in Layout Builder by hiding uncommon block plugins attempts to solve this so by simply hiding some of the clutter behind a "more" link (not sure this is a great solution; it was more of a quick-and-dirty stop-gap back when we were advocating for this problem to be a stable release blocker for Layout Builder)

I think what we should do in this issue (or maybe sub-issues, but let's try to get a "vision" together here first) is:

- Brainstorm some solutions for this general problem (maybe also investigating into how other CMSes have solved this problem in their page building tools)
- If we stick with categories, come up with a sensible, "human readable" list of categories for blocks to be placed in (bearing in mind contrib will need to put things here too)
- Come up with an "MVP" we can try and get done in relatively short order, so we can ideally try and get something into 8.8 before October.

Thoughts/sketches welcome!

In D7 the search page ("/search/node" or "/search/user") titles are rendered from the "Label" field in admin search setting page.
But in D8 the search page ("/search/node" or "/search/user") titles are displayed as "Search" instead of rendering from the "Label" field under admin search setting page.

Attached the search settings page screenshot with highlighted label field for reference.

Problem/Motivation

An old migration configuration, using migrate_plus and migrate_source_csv, used the following definition for migration dependencies. This old, malformed migration_dependencies broke all migrations. This is on 8.1.10 and latest versions of migrate_plus.

migration_dependencies:
  - csv_migrate_story

whereas it should have looked more like:

migration_dependencies:
  required:
    - csv_migrate_story

So, even though it wasn't related to the new migration, it caused the following exception, making me thing there was something wrong with the new migration:

TypeError: Argument 1 passed to Drupal\migrate\Plugin\MigrationPluginManager::expandPluginIds() must be of the type array, string given in             [error]
Drupal\migrate\Plugin\MigrationPluginManager->expandPluginIds() (line 138 of
/var/www/drupalvm/web/core/modules/migrate/src/Plugin/MigrationPluginManager.php).
TypeError: Argument 1 passed to Drupal\migrate\Plugin\MigrationPluginManager::expandPluginIds() must be of the type array, string given in /var/www/drupalvm/web/core/modules/migrate/src/Plugin/MigrationPluginManager.php on line 138
TypeError: Argument 1 passed to Drupal\migrate\Plugin\MigrationPluginManager::expandPluginIds() must be of the type array, string given in Drupal\migrate\Plugin\MigrationPluginManager->expandPluginIds() (line 138 of /var/www/drupalvm/web/core/modules/migrate/src/Plugin/MigrationPluginManager.php).

Proposed resolution

Give a more meaningful error message when migration_dependencies isn't structured correctly.

Remaining tasks

Code it.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

A recurring issue is that the Drush queue worker doesn't match the logic for queues processed by cron, leading to subtle bugs.

https://github.com/drush-ops/drush/issues/4032

Let's refactor queue processing out from the Cron class so it can be reused by other modules or Drush, without relying on cron itself.

Please forgive my suggestions as a non-developer.

The permission to translate own content or any content is important.
In the absence of this permission, translating means that the site operator always does.
A role that has the permission to translate any content has the right to translate it without the permission of the content owner.

There are sites where registered users can freely post contents.
The right to translate content is in principle owned by the content owner.
Of course, it is possible to give translation rights to third parties.

Therefore, the right to translate your own content and the right to translate others' content must be separated.
Permissions such as posting, editing and deleting nodes follow this principle.
Please follow the principle of translation permissions.

This problem seems to exist for a long time since Drupal7.
I discovered that several issues exist.
I hope that the translation initiative will be established and resolved.
Please,please,please!

Thank you.

Problem/Motivation

Followup to #3060391-9: Cleanup usage of PHPUnit 4.8 aliased classes

There are many, many (many...) references to \PHPUnit_Framework_MockObject_MockObject in core, mostly within docblocks. These are left over from PHPUnit 4.8.

These should be changed to reference \PHPUnit\Framework\MockObject\MockObject.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

What are the steps required to reproduce the bug?

I created book migration configuration based on docroot/core/modules/book/migrations/d7_book.yml to migrate book data from Drupal 7 to Drupal 8. Running drush migrate-import works, but when I add the --update flag, all items fail with errors.

What behavior were you expecting?

I was expecting that the migration would update like node and other migration plugins, error free.

What happened instead?

When running the book migration with the --update flag, all items fail and the following errors occur for each item:

 [error]  Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '2826' for key 'PRIMARY': INSERT INTO {book} (nid, bid, pid, weight, depth, p1, p2, p3, p4, p5, p6, p7, p8, p9) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13); Array
(
    [:db_insert_placeholder_0] => 2826
    [:db_insert_placeholder_1] => 2816
    [:db_insert_placeholder_2] => 2816
    [:db_insert_placeholder_3] => 5
    [:db_insert_placeholder_4] => 2
    [:db_insert_placeholder_5] => 2816
    [:db_insert_placeholder_6] => 2826
    [:db_insert_placeholder_7] => 0
    [:db_insert_placeholder_8] => 0
    [:db_insert_placeholder_9] => 0
    [:db_insert_placeholder_10] => 0
    [:db_insert_placeholder_11] => 0
    [:db_insert_placeholder_12] => 0
    [:db_insert_placeholder_13] => 0
)
 in Drupal\Core\Database\Connection->handleQueryException() (line 683 of /app/docroot/core/lib/Drupal/Core/Database/Connection.php). 
 [error]  SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '2826' for key 'PRIMARY': INSERT INTO {book} (nid, bid, pid, weight, depth, p1, p2, p3, p4, p5, p6, p7, p8, p9) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13); Array
(
    [:db_insert_placeholder_0] => 2826
    [:db_insert_placeholder_1] => 2816
    [:db_insert_placeholder_2] => 2816
    [:db_insert_placeholder_3] => 5
    [:db_insert_placeholder_4] => 2
    [:db_insert_placeholder_5] => 2816
    [:db_insert_placeholder_6] => 2826
    [:db_insert_placeholder_7] => 0
    [:db_insert_placeholder_8] => 0
    [:db_insert_placeholder_9] => 0
    [:db_insert_placeholder_10] => 0
    [:db_insert_placeholder_11] => 0
    [:db_insert_placeholder_12] => 0
    [:db_insert_placeholder_13] => 0
)
 (/app/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php:783)