| Field |
Value |
| Reporter |
@axeluhl |
| Assignee |
@axeluhl |
| Product |
Sailing Race Analytics |
| Component |
Architecture |
| Version |
unspecified |
| Hardware |
All |
| OS |
All |
| Severity |
normal |
| Priority |
P2 |
| Created |
2026-03-24T23:18:56Z |
| Original Bug |
Bug 6225 |
When waiting for a new archive server candidate to become ready, ArchiveCandidateMonitoringBackgroundTask submits tasks to the default background executor. Some tasks, however, seem to "die" without notice, breaking the re-scheduling loop and eventually leaving the user uninformed about progress or lack thereof.
For example, we assume that a compareServers job failed with a NullPointerException because the reverse proxy servers were re-started in between and most likely led to an error response status rather than a successful code 200. So a null JSON object would have been tried to get de-serialized. However, the NPE never showed, and no warning or other log message about the failure and any expected re-scheduling of the task showed.
We should create a failing test for this and analyze what can go wrong in the task re-scheduling loop upon exceptions.
When waiting for a new archive server candidate to become ready, ArchiveCandidateMonitoringBackgroundTask submits tasks to the default background executor. Some tasks, however, seem to "die" without notice, breaking the re-scheduling loop and eventually leaving the user uninformed about progress or lack thereof.
For example, we assume that a compareServers job failed with a NullPointerException because the reverse proxy servers were re-started in between and most likely led to an error response status rather than a successful code 200. So a null JSON object would have been tried to get de-serialized. However, the NPE never showed, and no warning or other log message about the failure and any expected re-scheduling of the task showed.
We should create a failing test for this and analyze what can go wrong in the task re-scheduling loop upon exceptions.