Server endpoint for surfacing discrepancies #2026
Conversation
nikhilb4a
force-pushed
the
nikhil/1912-discrepancy-report-in-app
branch
from
da73188 to
05527ec
Compare
|
Note - Tests will be added soon, but a review of the endpoint would still be appreciated to evaluate the design decisions |
| contest.id, jurisdiction_id, batch_name, discrepancies | ||
| ) | ||
| discrepancies_by_jurisdiction[jurisdiction_id].append(contest_discrepancies) | ||
| return discrepancies_by_jurisdiction |
There was a problem hiding this comment.
Unfortunately, this logic will need to take into account combined batches. See the discrepancy counting endpoint above and/or sampled_batch_rows function in reports.py (which computes the discrepancy report). May be best to add this as a follow up once we get the rest of the feature working.
nikhilb4a
force-pushed
the
nikhil/1912-discrepancy-report-in-app
branch
from
83c2b75 to
a83c83c
Compare
nikhilb4a
force-pushed
the
nikhil/1912-discrepancy-report-in-app
branch
from
a83c83c to
0678197
Compare
server/api/jurisdictions.py
Outdated
| def create_nested_discrepancies_dict(): | ||
| return defaultdict( | ||
| lambda: defaultdict(lambda: defaultdict(lambda: defaultdict(int))) | ||
| ) |
There was a problem hiding this comment.
Based on the way you're using this, I don't think you need the last two levels of defaultdict. I think this will suffice:
defaultdict(lambda: defaultdict(dict))Also maybe just inline it since it's only called in one place?
There was a problem hiding this comment.
Ah yeah, thanks. I initially separated it out anticipating I would also need to use it for the future ballot comparison discrepancy function, but with the shorter init then inline is fine
This PR adds a server endpoint for getting discrepancies, and for now only adds the implementation for batch comparison audits.
Next, I plan to wire together the rest of the flow to the client, and then add implementation for ballot comparison audits. My plan is to build a bit more incrementally, so the PR doesn't become too much for me to reason about as I go.
For now, thought it might be helpful to agree upon the API and models I set up, of course subject to some minor changes if needed when the rest of the feature is built out.
Sample response received by the Client from this endpoint -
