Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[ISSUE] Another entry can take a slot while its owner is disabled or reloading

Abierto
  • ¿Algo no está bien?
#1,691 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
24/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend

Línea de trabajo

Start with the slot claim logic in core/registry.py, specifically want and _check_free, and trace what happens to a slot when its owning entry is disabled or reloading. Reproduce the steps in the issue: two entries configuring the same slot on one lock, then a change to the second entry while the first is down. The open question is which ownership rule to adopt, so agree on one with maintainers before coding. Done means the owner keeps its slot across disable and reload, and a test covers the hand-off cases.

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

Descripción

bug
What happened?

Found while reviewing #1690 (milestone 5c of the clean-room core rebuild). It also happens before #1690, so it was left out of that PR.

Two config entries can configure the same slot on the same lock. This only happens with older storage. The first entry to claim the slot owns it (core/registry.py: want / _check_free).

While the owning entry is disabled or reloading, it releases the lock but keeps no claim on the slot. If the other entry's slot changes during that window, for example its condition entity changes, that entry claims the slot. When the owner comes back, the slot is already owned by the other entry, and the owner loses it for good.

Expected: a disabled or reloading entry keeps its slot. Another entry should get it only through an explicit hand-off: give-up, the lock being removed from the owner, or the owner being deleted. #1690 already makes reload and disable keep the slot when no other entry is involved.

Open design question: which entry should own a slot that two entries configure? Options:

  • remember the owner across disable and reload, so the other entry can't claim the slot meanwhile;
  • reject the duplicate configuration outright, and repair it on migration;
  • make the claim order deterministic, e.g. oldest entry wins.
Steps to reproduce the issue
  1. Set up two LCM entries, A and B, that both configure slot N on the same lock (older storage allows this). A owns slot N.
  2. Disable or reload entry A.
  3. While A is down, change B's slot N, e.g. flip its condition entity.
  4. Re-enable A, or let its reload finish.
  5. B now owns slot N, and A's configuration for slot N is no longer applied.
Home Assistant Version

n/a (found in code review)

What version of Lock Code Manager are you running?

feature/clean-room-core (#1690 head 5f39491d); present before #1690 too

Lock make and model

Any

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ej3snRj69NSu2qB2b9td9J

Lenguaje dominante
Python
Estrellas
108
Forks
18
Merge medio
2 h 7 min
PR fusionados (30 d)
130

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.