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

A bulk-add config flow can wait hours on a slow lock with nothing on screen

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

Maintainers usually reply within 1 day

A pull request for this has already been merged.

  • #1554 by @raman325 — merged

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Stale
Tech stack
python
Domain
backend

Research direction

Start with async_allocate_for, which walks locks serially, and the two interactive callers at config_flow.py:264 and services.py:513. Read how OPERATION_TIMEOUT and the per-read budgets interact with the window width, and why #1529's ALLOCATION_READ_TIMEOUT fired first. The issue asks for a design decision among a smaller per-operation budget, a size-scaled budget, or progress feedback, not a new constant. Done means that decision is recorded and implemented, and that slot_scope still takes effect.

Written by the indexing model from the issue text.

Description

bug

Found reviewing #1529, and attempted there before being reverted — the cap chosen was below everything it bounded.

Each lock's occupancy read is bounded by that provider's budget, but async_allocate_for multiplies that by the width of the window and then walks locks serially with no aggregate bound. A 40-user first pass on ZHA is ~3600s per deadline. Both callers are interactive — the config flow (config_flow.py:264) and the add_users action (services.py:513) — so a person sits in front of a frozen dialog with no explanation.

Why the obvious fix is wrong

#1529 added a 120s ALLOCATION_READ_TIMEOUT over the whole of async_allocate_for. Every per-operation budget is floored at OPERATION_TIMEOUT = 600.0, so the aggregate cap fired first, every time, on the only path that reaches the occupancy scan. That:

  • made slot_scope=len(wanted) — the actual fix for #1528 — inert, since the cap always bound before the scoped budget could;
  • failed locks that work on main today: one needing 120–600s of honest reading now returns occupancy_unknown, which is the reported bug appearing on hardware that never had it.

The real tension

A person-scale wait (~1–2 min) and a per-slot budget floored at ten minutes cannot both be satisfied by a single number. Options worth weighing:

  • a smaller per-operation budget on the interactive path, rather than an aggregate cap over generous ones;
  • a budget that scales with the users being added, so small adds stay snappy and bulk adds are allowed to take longer;
  • progress feedback instead of a bound, so a long read is legible rather than silent.

This needs a decision about which of those, not another constant.

Additional information

  • Related: #1523, #1528, #1529
Dominant language
Python
Stars
108
Forks
18
Avg merge
1h 50m
Merged PRs (30d)
103

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.