The Javadoc on PolarDataService.runWhenPolarLoadingFinishedFor (interface),
PolarDataMiner (impl) and the RacingEventServiceImpl.scheduleWindEstimationInstallation
caller all read as if the callback fired once the fixes belonging to the given
race had drained. In reality the loading pipeline (preFilteringProcessorForLoadedFixes)
is shared across all races and has no per-race completion tracking, so the
callback fires only on a global drain: when the fixes of every race ingested so
far have been processed.
The race parameter does not scope the wait; it only gates WHEN the callback may
attach to the shared drain, via two conditions that must both hold: (1) the
race's own fixes have been ingested (so the callback can't fire on a pipeline
that is merely momentarily idle before this race was queued), and (2)
markLoadingOfAllRacesToRestoreStarted() has been signalled (so an idle window
between two startup races' ingestion bursts isn't mistaken for a real drain).
This global-wait behavior is deliberate: we want the polar model to reflect all
loaded data before any maneuver-based wind estimation is installed, and we accept
the resulting startup sequentiality (an early race's estimator install waits
behind the whole loaded-fix backlog). Documentation only; no behavior change.
The method name is kept as-is.
when this exception is thrown, catch it and return null for the table
entry looked for; this is intended to cause the waitUntil method to try
again instead of failing with the exception
Locally, the lock duration was not long enough to last until the admin
logged in to unlock them. This bypassed the need to interact with a
dialog locally, and so the test was still succeeding even after an
interaction command for this dialog was removed. This duration was long
enough for the server however, and so the dialog demanding interaction
would appear and crash the test. The expected lock duration has been
extended by trigger +1 failed login attempts as well as the dialog
interact.
Popup dialog replaced with toast notification for success. Although the
reason behind this bug is yet not understood because the dialog should
have been accepted by the corresponding method in the PO, as it has done
before, replacing it with a toast notification should nevertheless
remove the possibility of it happening again.
A method was exposed from UserManagementWriteService for bulk unlocking
a selection of users by their username. An 'extra' property was added to
successInfo class to return usernames without disturbing GWT
serialization. corresponding test is also written.
In SecurityServiceImpl, the
UserManagementException.PASSWORD_AUTHENTICATION_CURRENTLY_LOCKED_FOR_USER
property is used to return an error message with a constant referrable
string that is checked against a condition elsewhere in the code. I had
caused issues in the code by replacing this referenced string with a
custom error message without accounting for its usage elsewhere, causing
faults. This has been reversed.
fail2ban didn't extend the lock when a lock already existed on said IP. this was remedied. the test failed because selenium was looking for a component using the driver, so from the head of the tree, instead of from the webelement, which was at a specific lower point in the element tree and thus is unaffected by selenium IDs being similar. the findElement is now done from a method on the webelement.
Axel Uhl
Masha Kashirina
Sohaib Baig