When reindexing, some events may incorrectly be displayed as "Scheduled" instead of "Processed" or "Failed"

Steps to reproduce

Steps to reproduce:
1. Make sure you have events without workflows in your system, for instance, delete the workflows associated to a finished event
2. Rebuild the index by issuing a POST call to <admin_server>/admin-ng/index/recreateIndex
3.

Actual Results:
The events are incorrectly shown as "Scheduled"

Expected Results:
The events should be listed as "Processed", just like before

Workaround (if any):
One could have a dummy workflow that produces non effect in the MP at all, but would mark the event as "Processed" again.

Activity

Show:
Rubén Pérez
December 6, 2017, 4:18 PM

The method that updates an event's status is a bit flawed: the "scheduled" status is applied by default, when a) no current workflow ID exists (the event is running or has run a workflow), and b) no current recording ID exists (the event is scheduled or is being recorded). The event status is not updated when workflows associated to an event are deleted, and therefore it stays as "processed" when that happens.

The issue affects also those events with workflows that contain a mediapackage instance with an episode catalog that cannot be found or parsed in any way. This is particularly frequent during a migration to 4.0, because some workflows are bound to contain dublincore catalogs with archive URIs, which in 4.0 will no longer be valid. Such events will be displayed as "scheduled" because an exception when trying to parse the catalog will prevent the workflow ID to be updated in the event instance.

I'm currently working on a fix, but at the moment it only works partially.

Sven Stauber
December 7, 2017, 2:54 PM

Note that I don't think that events in "Processing failed" will be recognized as such during a Index rebuild in case you have deleted the associated workflows. The reason is that Opencast does not track an individual event status at all but rather determines that status heuristically. If you have deleted the workflows, you essentially have removed that information ("Processing failed") from your system and therefore caused a data inconsistency.

Assignee

Sven Stauber

Reporter

Rubén Pérez

Severity

Incorrectly Functioning Without Workaround

Tags (folksonomy)

None

Components

Fix versions

Affects versions

Priority

Blocker
Configure