Improve continuous export failure recovery by moving the export operation "progress marker" from USB drive to VxScan store #4213
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
arsalansufi
force-pushed
the
arsalan/ce-failure-recovery-refinements
branch
from
51f3cf9 to
131953a
Compare
arsalansufi
commented
Nov 15, 2023
| // If we're storing an accepted sheet that needed review, that means that it was "adjudicated" | ||
| // (i.e. the voter said to count it without changing anything). | ||
| if (interpretation.type === 'NeedsReviewSheet') { | ||
| store.adjudicateSheet(sheetId); | ||
| } | ||
|
|
||
| // Gets reset to false within exportCastVoteRecordsToUsbDrive | ||
| store.setIsContinuousExportOperationInProgress(true); |
There was a problem hiding this comment.
I actually implement this store method in the next commit
| setExportDirectoryName(exportDirectoryName: string): void; | ||
| setIsContinuousExportOperationInProgress( | ||
| isContinuousExportOperationInProgress: boolean | ||
| ): void; |
There was a problem hiding this comment.
Rather than having all these methods be optional on the ScannerStore interface, I've now updated ScannerStore to be a union of two distinct interfaces, one for the central scanner and one for the precinct scanner (still sharing what I can though, via ScannerStoreBase)
adghayes
approved these changes
Nov 15, 2023
apps/scan/backend/src/store.ts
Outdated
| from is_continuous_export_operation_in_progress | ||
| ` | ||
| ) as { isContinuousExportOperationInProgress: number } | undefined; | ||
| return Boolean(row?.isContinuousExportOperationInProgress); |
There was a problem hiding this comment.
I just added a type + basic utils to admin/backend/src/store.ts for being more explicit about these boolean conversions. What do you think about copying those or moving them to a shared library to use in this store file?
There was a problem hiding this comment.
Oh nice! Can move to a shared location
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Easiest reviewed by commit
Overview
Issue link: #4096
This PR improves continuous export failure recovery by moving the export operation "progress marker" from the USB drive to the VxScan store.
We currently write a
.vx-export-in-progressfile to the USB drive at the start of every continuous export operation. We then delete the file when the operation completes. If an export operation fails midway and a machine has to be restarted, the existence of that file on startup tells us that a resync is required.The main downside to using a file on the USB drive is that the write of that file itself may fail. In that case, the machine won't know that a resync is required after restart. Switching to a piece of state on the machine is more robust, especially when paired with a transaction.
Testing
Checklist
I have added logging where appropriate to any new user actions, system updates such as file reads or storage writes, or errors introducedN/A