Closed vteague closed 2 months ago
Update: This only happens when the IRV contest is targeted, but there are no assertions for the contest. It can be solved by enforcing a prohibition against targeting a NOT_AUDITABLE contest.
TODO: Check how/whether this same prohibition is enforced for plurality; do the same.
It's possible this also happens when there is an IRV contest with no assertions, regardless of whether the contest is targeted.
Update: It definitely happens at least sometimes when the assertions are all there. Not sure exactly what the conditions for occurrence are.
Update 2: It's unclear whether this actually has anything to do with IRV. The problem seems to arise when startAuditRound tries to get the ASM state for the county dashboard, but for some reason this fails.
Interestingly, CountyDashboardASM is throwing a warning in Jetbrains, saying that it should have a parameterless constructor and an ID (which it doesn't). Not sure if this is related.
The database definitely does have a record for CountyDashboardASM for the IDs it's complaining about.
Now throwing a warning about apparent deadlock:
Possibly this is triggered when a county has logged in and uploaded CVRs, but there are no ballots to audit in that county.
Actually this has nothing to do with IRV at all, and is present in the earliest fork from cdos/colorado-rla (after the minimal dependency-upgrades we had to make to get it to run).
This is the error thrown at this (very early) point in the history: https://github.com/DemocracyDevelopers/colorado-rla/commit/57bbd49beb964019ea810fb2d2ad72916b9b4ec1
which is the same error thrown at the same point. (Though it complains about the DoS ASM, not the county ASM.)
Updated issue title to match current hypothesis.
Steps to reproduce: Use the plurality-only data in colorado-rla/server/eclipse-project/src/test/resources/CSVs/PluralityOnly
I believe this is because Alamosa has uploaded CVRs, but has no ballots to audit.
If you do everything exactly the same, but target PluralityExample1 instead, which occurs in both counties' CSVs and hence gives both counties some non-empty audit samples, everything works fine.
The exception is thrown from PersistentASMStateQueries.get( ... , "DoS") when it is called from ASMUtitilties.save in StartAuditRound.java.
PersistentASMStateQueries::74 - query.getResultList() runs a query that looks OK to me, but causes a PersistenceException.
This is actually called by AbstractEndpoint::transitionAndSaveASM.
The underlying error is java.lang.reflect.InaccessibleObjectException: Unable to make private java.util.Collections$EmptyList() accessible: module java.base does not "opens java.util" to unnamed module @f8c1ddd
I believe this is caused by LongListConverter::convertToDatabaseColumn, for which the GSON.toJson( ... ) call seems to throw that exception when given an empty list.
This seems consistent with others who are experiencing similar issues, e.g.: https://github.com/google/gson/issues/1875 though I'm not certain it's the same.
I'm pretty sure this commit: https://github.com/DemocracyDevelopers/colorado-rla/commit/041b486df7d10bd11b70ba3d77e795668d000395 solves the problem.
However, I'm leaving the issue open, because I suspect other types of convertToDatabaseColumn have the same issue, and we should probably do the same thing to them too.
It's also not entirely clear to me what we should do with nulls. It's possible we should leave nulls as null, and merely special-case the empty list.
Updated to leave nulls as null, while still special-casing the empty list.
When the state dashboard initiates an audit, with an IRV contest as the targeted contest, corla throws an error stating that sample ballots cannot be generated.
The log file outputs: ERROR corla:87 - could not query database for persistent ASM statejavax.persistence.PersistenceException: Error attempting to apply AttributeConverter ERROR corla:76 - Unable to retrieve ASM state for class class us.freeandfair.corla.asm.DoSDashboardASM with identity DoS ERROR AbstractStateMachine:264 - ASM event DOS_START_ROUND_EVENT failed from state DOS_INITIAL_STATE
It's unlikely this is really because the attribute converter is buggy. Perhaps this is just because we have not (yet) enforced assertion generation before this step.