[ISSUE] A deleted user's code can keep working when the lock ignores the release clear

Cerrado
  • ¿Algo no está bien?
#1,622 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
43/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
authentication, backend

Línea de trabajo

Read async_release_managed_slot and the coordinator refactor planned after the current bug-fix PRs; the issue does not name files or tests. Trace how a deleted user's clear is confirmed and whether the slot can be read back after release. Done means an ignored clear is detected and retried, or raises a repair warning that the old PIN may still work.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug
What happened?

When a user is deleted, Lock Code Manager releases their slot and clears the code on the lock (async_release_managed_slot). If the lock acknowledges that clear without applying it, the deleted user's PIN keeps opening the door. Nothing reports it or retries.

Examples of a lock that does this:

  • a ZHA lock that answers with a success Default Response but drops the command;
  • a Z-Wave lock behind zwave-js-ui that receives an unsupervised User Code Set and ignores it.

Today Lock Code Manager reports the slot as empty after any clear that returns, so the problem is invisible:

  • the slot has already left the configuration, so no sync manager re-checks it;
  • the unmanaged-code sweep runs only at migration;
  • no repair is raised.

This is the same outcome as #1453 (deleted users kept working), reached through a different path: there the clear was never sent, here it is sent and silently ignored.

Expected: a release clear that the lock does not confirm is read back. If the code is still there, Lock Code Manager retries, or at least raises a repair telling the user the deleted user's code may still open the door.

Found while reviewing #1621 (closed). Doing the read-back properly depends on the coordinator refactor planned after the current bug-fix PRs, so this is tracked here until then.

Steps to reproduce the issue
  1. Use a lock that acknowledges a PIN clear without applying it: a ZHA lock replying with a success Default Response, or an unsupervised User Code Set through zwave-js-ui.
  2. Create a Lock Code Manager user with a PIN and let it sync to the lock.
  3. Make the lock ignore the next clear (on real hardware: a weak mesh link, or a lock that drops the command).
  4. Delete the user in Lock Code Manager.
  5. The slot shows as empty in Lock Code Manager, but the PIN still unlocks the door, and no repair is raised.
Home Assistant Version

2026.9.0

What version of Lock Code Manager are you running?

6.0.1

Lock make and model

Any lock whose clear can be acknowledged without being applied (seen in code review for ZHA and zwave-js-ui; not yet reproduced on hardware).

Anything else?

Related: #1453, #1621.

Lenguaje dominante
Python
Estrellas
112
Forks
20
Merge medio
2 h 57 min
PR fusionados (30 d)
158

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de raman325/lock_code_manager

Todos los issues de raman325/lock_code_manager

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.