Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#1,691 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
24/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Python
Stelle
108
Fork
18
Merge medio
2h 7m
PR unite (30g)
130

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di raman325/lock_code_manager

Tutte le issue di raman325/lock_code_manager

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.