Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#1,691 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
24/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
backend

Research direction

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.

Written by the indexing model from the issue text.

Description

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

Dominant language
Python
Stars
108
Forks
18
Avg merge
2h 7m
Merged PRs (30d)
130

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from raman325/lock_code_manager

All issues in raman325/lock_code_manager

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.