Report background job success/failure

[dannylamb]

If a background job fails, there's no immediate indication in the UI to tip off the end user. You'll not experience the behaviour that you're expecting, and you can always go and check the various logs, but that's not ideal for those without systems access.

When we push a message onto the queue for a background job, we should make a db record, and then update it appropriately at the end of the operation for either success or fail. We should then expose this to the user, either through a dashboard for all objects or a block that can be displayed on individual objects.

[dannylamb]

Linking to #942

[seth-shaw-unlv]

Well, Drupal 8 has an okay log interface. We could make a simple REST endpoint that Karaf could post Success and Failure events to.

The endpoint could be something simple like:

<?php
namespace Drupal\logger_rest\Plugin\rest\resource;
use Drupal\rest\Plugin\ResourceBase;
use Drupal\rest\ResourceResponse;
use Drupal\Core\Session\AccountProxyInterface;
use Psr\Log\LoggerInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException;
/**
 * Annotaation for post method
 *
 * @RestResource(
 *   id = "logger_post",
 *   label = @Translation("Logger POST"),
 *   serialization_class = "",
 *   uri_paths = {
 *     "https://www.drupal.org/link-relations/create" = "/api/v1/logger",
 *   }
 * )
 */
class LoggerRest extends ResourceBase
{
    /**
     * A current user instance.
     *
     * @var \Drupal\Core\Session\AccountProxyInterface
     */
    protected $currentUser;
    /**
     * Constructs a Drupal\rest\Plugin\ResourceBase object.
     *
     * @param array $configuration
     *   A configuration array containing information about the plugin instance.
     * @param string $plugin_id
     *   The plugin_id for the plugin instance.
     * @param mixed $plugin_definition
     *   The plugin implementation definition.
     * @param array $serializer_formats
     *   The available serialization formats.
     * @param \Psr\Log\LoggerInterface $logger
     *   A logger instance.
     * @param \Drupal\Core\Session\AccountProxyInterface $current_user
     *   A current user instance.
     */
    public function __construct(
        array $configuration,
        $plugin_id,
        $plugin_definition,
        array $serializer_formats,
        LoggerInterface $logger,
        AccountProxyInterface $current_user)
    {
parent::__construct($configuration, $plugin_id, $plugin_definition, $serializer_formats, $logger);
$this->currentUser = $current_user;
    }
    /**
     * {@inheritdoc}
     */
    public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition)
    {
        return new static(
            $configuration,
            $plugin_id,
            $plugin_definition,
            $container->getParameter('serializer.formats'),
            $container->get('logger.factory')->get('custom_rest'),
            $container->get('current_user')
        );
    }
    /**
     * Responds to POST requests.
     *
     * Returns a list of bundles for specified entity.
     *
     * @throws \Symfony\Component\HttpKernel\Exception\HttpException
     *   Throws exception expected.
     */
    public function post($data)
    {
        $response_status['status'] = false;
        if (!$this->currentUser->hasPermission('access content')) {
            throw new AccessDeniedHttpException();
        }
if(!empty($data->message->value)){
    $module = $data->message->module;
    $message = $data->message->value;
    switch($data->message->level){
        case 'DEBUG':
            \Drupal::logger($module)->debug($message);
            break;
        case 'ERROR':
            \Drupal::logger($module)->error($message);
            break;
        default:
            \Drupal::logger($module)->info($message);
            break;
    }
        }
        return new ResourceResponse('OK');
    }
}

(Spitballing here, this is completely untested...)

[ajstanley]

A super simple way of tracking derivative creation would be to add an additional parameter to the route used when we set file_upload_uri in the generateData method.
We'd start by creating a database table with fields for Job ID, Entity type, Entity_id, and status. When a derivative is requested a line would be added to the table with a status of 'started'. If we stuck the Job ID in the file_upload_uri, when the endpoint got the derivative it would know what the job id is.
The endpoint could update the table with the job status, either we got what we wanted, or we didn't.
It's a small amount of code, but it would cover us. (unless I'm missing something)

It would be trivial to create reports indicating how many jobs were in an incomplete status for any given entity (or group of entities)

(also just spitballing)