Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VxMark: PAT input shows up as not connected in HW diagnostic even when connected and working #5275

Closed
arsalansufi opened this issue Aug 19, 2024 · 1 comment
Assignees
Milestone

Comments

@arsalansufi
Copy link
Contributor

arsalansufi commented Aug 19, 2024

VxMark: PAT input shows up as not connected in HW diagnostic even when connected and working

This is very possibly specific to production and the 150s

Issue automatically created from Slack feedback reported by arsalan:
https://votingworks.slack.com/archives/CJU9MSC6S/p1724078551652199

@kshen0
Copy link
Contributor

kshen0 commented Sep 24, 2024

First, due to complexity of various PAT and diagnostic flows we should note

  • the PAT tutorial that a voter sees (when plugging a device in for the first time) is not related to this flow
  • there are backend and frontend components for the sys admin hardware diagnostic report ("Readiness Report")

The bug is that the "Connected / Not Connected" text reports on PAT device connection status ie. whether a sip & puff is plugged in. It should report on whether the PAT input and associated business logic works, which is technically:

  1. Whether the daemon is running (also implies the daemon can reach the firmware)
  2. Whether daemon, backend, and frontend business logic can correctly handle sip/puff signals from the device

Product decision

Change diagnostic report copy: change status text from "Connected / Not Connected" to "Available / Not Available". Assuming the daemon is running, the final result will always read like:

Subtitle: Test PAT Input (Sip & Puff)
Text: Available

Code changes

  • allow status text override in https://github.com/votingworks/vxsuite/blob/main/libs/ui/src/diagnostics/mark_scan_device_diagnostic_section.tsx#L32
  • call isAccessibleControllerDaemonRunning from here and here
  • on the 155, gracefully fall back to reporting PAT device connection status (current behavior)
    • this is because the 155 PAT daemon is separate from the accessible controller daemon. The 155 PAT daemon doesn't report its PID in the same way the accessible controller daemons do, so the mark-scan app doesn't have a clean way to check that the 155 PAT daemon is running. We don't want to invest in extending the 155 PAT daemon at this moment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants