fix(dashboard): improve high-density chore dashboard support#129
Merged
Conversation
…ning Implement the completed CHORE_DYNAMIC_ENTITY_LIFECYCLE plan for beta validation. - add a chore-scoped runtime sync contract with explicit mutation context - create and remove live chore sensors and workflow buttons without full entry reload - route service and options-flow chore CRUD through the shared runtime sync path - preserve omitted optional values in sparse chore edits while keeping explicit overwrite and clear behavior intact - expand regression coverage for runtime entity lifecycle, helper flows, and sanctioned reload boundaries - update README, test guidance, and archive the completed initiative documents Keep sanctioned system-settings reload behavior intact for non-chore paths. Validation: - ./utils/quick_lint.sh --fix - targeted pytest runtime-sync/options-flow suite: 100 passed Refs: #107 Plan: CHORE_DYNAMIC_ENTITY_LIFECYCLE_COMPLETED
What changed: - Added a dense scenario generator and committed 40-100 chores-per-user fixtures - Added opt-in stress tests for dashboard helper size and a representative claim flow - Updated scenario/testing docs to cover dense stress runs and live HA manual loading - Confirmed the current helper-size boundary is between 40 and 50 chores per assignee for the generated dense profile Why: - Reproduce issue #124 with the existing scenario framework instead of ad hoc setups - Establish a repeatable way to measure dashboard helper growth as chore density increases - Give us a stable baseline for future payload-reduction work in the dashboard helper sensors
Includes runtime chore shard helpers, shared dashboard snippet migration, dense scenario expansion through 120 chores per assignee, and focused shard validation/documentation updates. Known follow-up: tests/test_dashboard_helper_sharding.py currently still has two failing lifecycle cases covering reload reconstruction and small-edit shard-pointer publication on the main helper.
…nd accepted in importing systems Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #124
This PR delivers the Issue 124 architecture update for users with very high numbers of chores assigned to a single user.
The ChoreOps backend and data model were already sound. The real limitation showed up in how large chore lists were surfaced through Home Assistant helpers, sensors, templates, and dashboards. At around 135 chores per user, the old approach was pushing too much dashboard data through one helper surface, which created practical limits in payload size and frontend rendering.
To address that, this PR redesigns the dashboard data path so large chore lists can be split across multiple helper-backed chore lists when needed. In this PR, sharding means splitting a large chore list into ordered companion helper lists instead of forcing everything through one oversized helper.
Why this was needed
What makes ChoreOps different is that it intentionally exposes rich, meaningful state directly into Home Assistant rather than hiding everything behind a private backend database, proprietary cards, or an opaque application layer.
That design is a strength because it keeps the system open, visible, and flexible for users who want to build their own automations, dashboards, and workflows on top of Home Assistant. The tradeoff is that we also have to work within real Home Assistant limits around entity payload size, helper attributes, template evaluation, and frontend rendering.
This change was needed because the data model itself was not failing, but the old single-helper dashboard surface was no longer the right way to present that much chore data at very high per-user counts.
What changed
chores_by_labeltransport and rebuilt label grouping from chore rows in shared dashboard logic.User impact
Performance note
Even with the new architecture, very large dashboards can still feel sluggish when rendering long lists of complex custom-card rows. That is a frontend rendering constraint, not a backend correctness problem.
At larger scales, performance is better when views are broken into smaller targeted chore groups or when simpler cards are used for some workflows.