User interrupts screen timeout locking & causes python3-validity.service error

[ixnewton]

If when the screen lock is about to start after screen timeout, it is interrupted by a mouse/trackpad move python-validity has a problem causing the system to be unresponsive for maybe 30 seconds. The system log shows python3-validity is in some error state.

python3-validity.log

17/12/2023 10:13	open-fprintd	DEBUG:root:Release
17/12/2023 10:13	open-fprintd	DEBUG:root:do_release
17/12/2023 10:13	dbus-daemon	[system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by ':1.429' (uid=1000 pid=208318 comm="/usr/lib/kscreenlocker_greet --graceTime 60000 --k")
17/12/2023 10:13	dbus-daemon	[system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org.freedesktop.home1.service not found.
17/12/2023 10:13	python3-validity.service	DEBUG:root:>tls> 17: 04
17/12/2023 10:13	python3-validity.service	DEBUG:root:>cmd> 170303004084c939fc810c3712cedb024541e53c03d648c9dd7bb88c1f4dff0519604112646e34d87bab37d56048d928ac4d325bd936cecd8b93f016357bbae70f163415e1
17/12/2023 10:13	python3-validity.service	DEBUG:root:<cmd< 1703030040544df0c9f70904dc6e15f177e81869dba4d9dabe0e6ebda1c7e8d1c59b1561c671ec2ae77562899bd917a125158c5d814a8836ee9ad438d4d6f6eeb4ea0c58dd
17/12/2023 10:13	python3-validity.service	DEBUG:root:<tls< 17: 0000
17/12/2023 10:13	python3-validity.service	DEBUG:root:>tls> 17: 39f4010000f401000001ff002000000000ffff0000000000000000000000000020000000000000000000000000f401000000ff0020000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
17/12/2023 10:13	python3-validity.service	DEBUG:root:>cmd> 17030300b069581f220301481699cf608ff578f8a43f3044c4a71d5b1bdcc2f7c001bd2d73533d7f16d8ef77a222e2361dd22da922df8bd47bf200e52d3c758ee3e5dbff8ac248a9e352d3978ef9a7508e61bd86d3e01bff480f613818df900918652b8b18ec5824ffc1be358382e157a8bb99ddb24aaa2f87dd69c0002e12efbaecaae12fd155287a9420b932c48a2927f2e3256080875e193cc611964e003c97ff913e11c8cca754972e6490bedb6246e54f536f
17/12/2023 10:13	python3-validity.service	DEBUG:root:<cmd< 1703030040562954832b71cfce6052cf9d461fca98e9f63d272336e93f2bcd6e5700a9b81f000861aecf0e37728dd8845c07d60a8732278e4c783a047f7b175bcb2edb38bd
17/12/2023 10:13	python3-validity.service	DEBUG:root:<tls< 17: 0000
17/12/2023 10:13	ERROR:root	Traceback (most recent call last):
  File "/usr/lib/python3.11/site-packages/validitysensor/usb.py", line 128, in wait_int
    resp = self.dev.read(131, 1024, timeout=100)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/usb/core.py", line 1029, in read
    ret = fn(
          ^^^
  File "/usr/lib/python3.11/site-packages/usb/backend/libusb1.py", line 864, in intr_read
    return self.__read(self.lib.libusb_interrupt_transfer,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/usb/backend/libusb1.py", line 954, in __read
    _check(retval)
  File "/usr/lib/python3.11/site-packages/usb/backend/libusb1.py", line 602, in _check
    raise USBTimeoutError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBTimeoutError: [Errno 110] Operation timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python-validity/dbus-service", line 121, in run
    usrid, subtype, hsh = sensor.identify(update_cb)
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/validitysensor/sensor.py", line 906, in identify
    raise e
  File "/usr/lib/python3.11/site-packages/validitysensor/sensor.py", line 900, in identify
    self.capture(CaptureMode.IDENTIFY)
  File "/usr/lib/python3.11/site-packages/validitysensor/sensor.py", line 705, in capture
    b = usb.wait_int()
        ^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/validitysensor/usb.py", line 135, in wait_int
    raise CancelledException()
validitysensor.usb.CancelledException

[ixnewton]

Further testing shows that the screen locking setting to allow unlocking without password affects this problem. This can be set to 0 seconds or disabled (KDE plasma desktop) and avoids the problem.

My suggestion is that if an unlocking timer without a password is enabled then python-validity should do nothing until the screen is actually locked? A more graceful failure response would be preferred?