Enable/add of search pages leads to route not found exception

More on this...

The error is happening when the site tries to return you to admin/config/search/settings.

This page is an entity list for the SearchPage entity:

 *   controllers = {
 *     "access" = "Drupal\search\SearchPageAccessController",
 *     "storage" = "Drupal\Core\Config\Entity\ConfigEntityStorage",
 *     "list_builder" = "Drupal\search\SearchPageListBuilder",

Looking at SearchPageListBuilder::buildRow()

    // If the search page is active, link to it.
    if ($entity->status()) {
      $row['url'] = array(
        '#type' => 'link',
        '#title' => $row['url'],
        '#route_name' => 'search.view_' . $entity->id(),
      );
    }

So that is where the route is being requested.

As noted in the original issue filing, the route is being created in SearchPageRoutes (a RouteListener):

   $active_pages = $this->searchPageRepository->getActiveSearchPages();
    foreach ($active_pages as $entity_id => $entity) {
      $routes["search.view_$entity_id"] = new Route(
        '/search/' . $entity->getPath() . '/{keys}',
 ...

And here is SearchPageRepository::getActiveSearchPages()

  public function getActiveSearchPages() {
    $ids = $this->getQuery()
      ->condition('status', TRUE)
      ->execute();
    return $this->storage->loadMultiple($ids);
  }

So my guess is that after adding or enabling a route, the RouteListener isn't being invoked at all to define the new routes. If you refresh the page after getting the exception, all is well -- the route is defined by then.

Is there something we need to do to make this happen? And why don't the tests catch this???

I don't think there is any AJAX request happening here (re #2)?

Regarding test coverage, maybe you're talking about some unit tests?

We also have some tests for search page CRUD via the UI in SearchConfigSettingsFormTest::testMultipleSearchPages().

There's a spot where it uses the "add", but it only does:

    $this->drupalPostForm(NULL, $first, t('Add search page'));
    $this->assertRaw(t('The %label search page has been added.', array('%label' => $first['label'])));

And this passes (the message is shown, along with the exception). I guess drupalPostForm() doesn't care if the page it lands on has an exception on it, and WebTestBase doesn't care if there is an exception either, apparently.

And later on it does an enable with:

   // Enable the first search page.
    $this->clickLink(t('Enable'));
    $this->assertResponse(200);

and also doesn't check that the text on the search settings page comes back up.

So we should add a couple of lines to these tests to make sure the search settings page is generated, and probably an assertNoText('Exception') or something like that. Probably to all of the CRUD operations.

Huh. I attempted to add some tests to SearchConfigSettingsFormTest::testMultipleSearchPages() but I cannot reproduce the problem there. The add and enable operations get you successfully back to the search settings page without an exception. Perhaps this is due to how drupalPostForm() works, as opposed to the Real World?

Anyway, here's a test patch, but it doesn't fail, and when you look at the debug output the add/enable operations worked just fine and didn't take you to an exception page.

Setting to "needs work" since these tests don't really help the problem and definitely don't solve the problem.

OK, I think I see what you're saying about AJAX - you are saying that Disable and Enable are AJAX operations -- I guess they might be. They are coming from the Drupal\Core\Config\Entity\DraggableListBuilder class... no, from its parent, ConfigEntityListBuilder... no its parent, EntityListBuilder.

Are these AJAX? It's not obvious to me.

But anyway, this does not apply to Add. Add goes to a whole separate add form page, and then when the page submits you get back to admin/config/search/settings, which gives you the exception when you are in the real UI (the test UI apparently does not generate the exception).

In the real UI, if you go back to admin/config/search/settings after getting the exception, you are OK, so I don't think we should do a get on admin/config/search/settings in that patch in verifySearchPageOperations.

The other change, to check the path, seems like a good idea, but we should probably move it to a different method so that we won't move to a different page within verifySearchPageOperations (which is often done twice in a row).

Actually, I am pretty sure this is not specifically AJAX-related.

If you go to admin/config/search/settings and disable a search page, and then copy the URL it gives you for the Enable, something like:

http://wren/~d8git/admin/config/search/settings/manage/users/enable

(here "users" is the machine name of this particular page that I added manually), and paste that into a new tab of your browser, you can see the exception.

#2230091: Route rebuilding is not guaranteed to finish in time for the next request has now been fixed.

I just retested this:
- Install with standard profile.
- Go to Configuration > Search and Meta Data > Search pages (admin/config/search/pages)
- Disable then Enable the User search page. All is well.
- Add a new Content search page. All is well.

So, I'm going to now mark this as a duplicate of that other issue.