FreeAndFair
how to handle fictitious CVRs?
@nealmcb attempted to create a bogus CVR file by duplicating the same CVR line many times. How might the RLA Tool detect such bogus CVR files? CC @dmzimmerman
We asked CDOS about this today. They asked us for an example CVR file that shows this problem. @nealmcb, can you make that happen?
A sample file is available at test/zoo/invalid-cvr-dup-line.csv.
At the moment it is only in the test-bis branch.
Background:
The CVR file that @kiniry refers to is one I created with an early version of bootstrap_cvr.py which did not yet generate unique values for the initial columns of the CVR. The current version creates valid CVRs.
I've added a new invalid test CVR file at test/zoo/invalid-cvr-dup-line.csv for use in testing.
At the time the server read it in just fine, and the question here is whether the server should ensure that the fields "CvrNumber","TabulatorNum","BatchId","RecordId","ImprintedId" are all valid, and in particular that the CvrNumber is sequential and unique, and that the ImprintedId and and the 3 fields that make it up are unique. I believe that the plan, or the current code, requires that CvrNumber at least is unique.
I'm including a request for confirmation that we need not deal with fictional/bogus CVRs in Weekly Report #11 on this issue.
I don't see anything about this issue in Weekly Report 11, and I can find no documentation of a request from CDOS to have the RLA Tool detect fictitious CVRs. So I'm removing ask CDOS label.
