Show which Server Tasks are pending on Server view page

Created on 9 June 2025, 4 months ago

Problem/Motivation

From time-to-time, a Search API server will end up with some queued Server Tasks. The number of tasks shows up on the Server view page (entity.search_api_server.canonical at /admin/config/search/search-api/server/SERVER_MACHINE_NAME) as follows...

Pending server tasks

There is currently 1 task pending for this server.

Pending tasks are created when operations on the server, such as deleting one or more items, cannot be executed because the server is currently unavailable (which will usually also create an entry in the Drupal logs). They are automatically tried again before any other operation is executed and the operation is aborted if the tasks could still not be executed, or if there are too many pending tasks to be executed in a single page request. In the latter case, you can use this form to manually execute all tasks and thus unblock the server again.

... below this message is an Execute tasks now button. Note this part of the page is built in \Drupal\search_api\Form\ServerStatusForm::buildForm().

However, it doesn't show what Server Tasks are queued, or the order that they're going to be executed in.

User story: As a search administrator or developer, I want to know what tasks are queued, and the order that they will be executed in, so that I can predict problems or debug why the queued tasks are not working.

Steps to reproduce

I'm not sure exactly how to get a server to end up with queued tasks.

Proposed resolution

Update \Drupal\search_api\Task\ServerTaskManager to return an array of pending \Drupal\search_api\Entity\Tasks for a given Server.

Update \Drupal\search_api\Form\ServerStatusForm::buildForm() to show a list of pending task types in order.

In Drush's REPL, the following snippet of code returns a list of pending tasks for a server:

  foreach (\Drupal::service('entity_type.manager')->getStorage('search_api_task')->loadByProperties(['server_id' => 'SERVER_MACHINE_NAME']) as $task) {
  echo $task->getType();
  }

Note that, currently, the task types only have machine names (i.e.: they don't have human-readable labels). Not sure if we want to add human-readable labels...

  1. addIndex
  2. updateIndex
  3. removeIndex
  4. deleteItems
  5. deleteAllIndexItems

Note that I'm considering the following out-of-scope, but I might file follow-up issues...

  1. deleting/clearing tasks
    (i.e.: if I know that a task is not going to work, or will do something that I don't want);
  2. saying that a server does not support certain tasks
    (i.e.: if my organization has only one server, and I need to share that server with other teams, and an administrator and gives me an index on that server to use, the administrator not give Search API permission to addIndex, or removeIndex)

Remaining tasks

  1. Write a patch
  2. Review and feedback
  3. RTBC and feedback
  4. Commit
  5. Release
Feature request
Status

Active

Version

1.0

Component

General code

Created by

🇨🇦Canada mparker17 UTC-4

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @mparker17
  • 🇨🇦Canada mparker17 UTC-4

    (Updated the code snippet in the issue summary to use search_api.task_manager to load the tasks by properties)

  • 🇨🇦Canada mparker17 UTC-4

    (fix typo in new code snippet)

  • 🇨🇦Canada mparker17 UTC-4

    Okay, I have created a merge request with a simple solution. Feedback welcome!

  • Pipeline finished with Success
    4 months ago
    Total: 329s
    #519918
  • Status changed to Needs review about 1 month ago
  • 🇦🇹Austria drunken monkey Vienna, Austria

    drunken monkey made their first commit to this issue’s fork.

  • 🇦🇹Austria drunken monkey Vienna, Austria

    Thanks for posting, this is a great idea! I do think this could be helpful to users from time to time. And brilliant that you already included test coverage!

    However, I don’t think it’s appropriate to just show this list any time there are pending tasks, for two reasons:

    1. For inexperienced users, this will just be confusing without helping them at all – we want them to just click “Execute tasks”, not make them think they need to understand what is happening. (If it doesn’t work, they will be stumped either way.)
    2. Sites have been known to accumulate vast amounts of pending tasks. We don’t want to WSoD the page in this case.

    For this reason, I think we need an extra page for this list – which, come to think of it, might just be a pre-configured view for the Task entity? We could then just link to that page and not overload this already confusing wall of text further. (An additional advantage of a view would that we could then also link to that from the Overview page, without filtering for a particular server.)
    Not sure whether there are pitfalls with the view idea (I think the fact that this would remove the functionality for sites where Views is not installed would be fine), but I do think this needs to be a separate page.
    Would you be willing to make the necessary changes to the MR?

    In any case, thanks a lot again for this!

    PS: Sorry for the late reply, I’m unfortunately a bit behind on my issue queue work.

Production build 0.71.5 2024