More finegrained viewer update events

[lucaro]

The current event structure is to coarse and triggers unnecessary updates. One causes the target view to be reset whenever new scores from a task that requires judging comes in. There should probably be dedicated events for score updates, submission updates and task updates, rather than having this all in one.

[lucaro]

After closer inspection, it turns out that the task update message is already rather specific for events that relate to a change in submissions or scores. The viewer should therefore already be able to properly distinguish what to update, since changes in tasks have a different event. The issue with the reset in the display of the target in case of score changes is therefore a viewer-side one.

[sauterl]

@ppanopticon what is the status on this? I guess the main objective was to not have updates (visually) for instance, when a new task is active in the viewer and judges are still working on their queue within the same evaluation.

[ppanopticon]

I'm not quite sure if this is still an issue after the latest refactoring and what exactly the design goal of this issue is.

[lucaro]

The goal is to avoid superfluous updates. Specifically, the behavior that the playback of the query target of a task is affected by incoming judgments of another task. Task update messages can be ignored if the viewer is currently showing a different task, etc.

[ppanopticon]

This is not something we can handle in the UI without completely rewriting the way these WebSocket messages are being processed in the RunViewer, which I do not have time to do.

So either we leave it as it is or we handle this in the backend, e.g., by not sending a message in updateSubmission() if the ID of the the submission's task does not match the current task.

Generally, it seems questionable to me, if we even need an update in such cases at all.

[ppanopticon]

Based on our discussion of July 3rd, we leave this as it is for now. For future reference, here is the state of the discussion:

Issue

• Currently, judgements of task A (over, deferred verdict) cause viewer updates for task B (which is ongoing). This can lead to undesired issues (sound effects being played, previews being reloaded).
• Since these changes are all triggered by WebSocket messages, which hold very little information, the viewer currently cannot know, whether a event should be acted upon or not.
• Furthermore, even if these messages were to be extended, the structure of the viewer makes it larger undertaking, to actually propagate all the required information to the different viewer components.

Solution

Conceptually, one should extend the WebSocket messages considerably to support the different constellations. Most importantly, it should have a notion of:

• The ID of the evaluation the message belongs to.
• The ID of the task that was active at the event-time
• Enumeration of the type of event (what happened) in a more fine-grained manner than what we have right now
• Context information (e.g., when a verdict is updated, the context holds information about the task the verdict has been updated for, which can be different from the task ID)

In the viewer, this message payload must be available at all levels of processing. Currently, a message simply triggers the reload of the run state and the message itself is discarded.