Pagination does not work correctly for comment fields when using Layout Builder

Found the same bug. Due to this issue i have deferred my Drupal 7 site upgrade.

This is still happening on Drupal 10.1.6 and 10.1.7-dev.

It also happens on 10.2.0-dev. pagination links go to "page=1,0" for the second page. If a pager ID other than "0" is set on the comments block (e.g. "1"), the links go to "page_id=,1" and then everything works.

This seems to go like this:

1. CommentStorage::loadThread is called twice, from some kind of pre-render hook. I'm not yet sure why.
2. The loadThread method extends the query with a PagerSelectExtender class, which handles the actual pagination. Only the class name is set. When the PagerSelectExtender is instantiated, its element member is not set.
3. When the query is executed, PagerSelectExtender::execute is called, which in turn calls PagerSelectExtender::ensureElement. Since no element is set, this sets the element member to "$this->connection->getPagerManager()->getMaxPagerElementId() + 1".
4. On the first run of loadThread, this results in element=0, since the default value of the getMaxPagerElementId getter is -1.
5. On the second run, the first run already registered the pager with the pager manager and the element ID 0, so by adding 1 we are now getting element=1.

The question remains, why only when using the Layout Builder the pre-rendering of the page calls LayoutBuilderEntityViewDisplay::buildMultiple (line 268) twice. I think, the next step should be a test case showing that problem.

I know what happens, and good news: This can easily be remedied on your page. I also can't stop laughing at how easiy this is once you understand it and how dumb Drupal behaves here.

What happens is this:

1. You have a content type, e.g. the basic page, and set up its fields. At some point you add the "comments" field to it and Drupal will add it to the view display of the content type. If you view an entity of this type, the comments will be rendered and everything is fine.
2. You decide that you want to use the Layout Builder for this content type and activate it on the content type's "Manage display" page. All the fields that you previously configured here are now gone and you have an empty Layout. You fill the default layout of the content type and also add the comments block to it. The page for an entity of this type is rendered with the blocks yoo configured in its Layout, and everything looks fine.
3. The fields that you previously configured are not gone, though, they are just not visible anymore. You can see this when exporting this content type's configuration. Look into the file, e.g. "core.entity_view_display.node.page.default.yml", and you'll see the old fields under the "content" section and the new Layout Builder blocks in the "third_party_settings" section. For a brand-new content type you can also test this: Enable the Layout Builoder, disable it again and see that all your previous fields are still there. For established content, disabling the Layout Builder is not allowed anymore.
4. Now, when Drupal renders the page, it apparently first looks at the configured fields in the "content" section and renders them. Then, the Layout Builder comes into it. It throws the previously rendered content away, looks at the configured blocks and renders them. The latter is was you see on the page.

This is quite a wasteful approach, and I'm sure that there should be a way to recognize early on that this content uses the Layout Builder and therefore nothing in the "content" section of its view display needs to be rendered. This ticket should probably be renamed accordingly.

For the workaround: Export the configuration, move the comments from "content" to "hidden" and re-import it.

Thanks for the thorough investigation and explanation @Ammaletu! I was very confused as to why my debugger was breaking on the comments view builder 2 times. This is also good knowledge to keep in mind that every field which remains rendered in the default entity view mode goes through the render process.