Skip to content

hotfix(projects): canvas+task element_id index boot-brick (upgrades brick without this)#1853

Merged
jaylfc merged 1 commit into
masterfrom
hotfix/canvas-task-index-boot-brick
Jul 16, 2026
Merged

hotfix(projects): canvas+task element_id index boot-brick (upgrades brick without this)#1853
jaylfc merged 1 commit into
masterfrom
hotfix/canvas-task-index-boot-brick

Conversation

@jaylfc

@jaylfc jaylfc commented Jul 16, 2026

Copy link
Copy Markdown
Owner

Boot-brick fix. The canvas and task stores' element_id index lived in SCHEMA, which BaseStore runs before _post_init. On an existing pre-element_id DB the index creation crashes with no such column: element_id before the migration adds the column, crashing controller boot on upgrade. Reproduced live: the Pi bricked on startup after pulling this code. CI missed it because fresh DBs get the column from SCHEMA. Same class + fix as the registry index (#1841). Move both indexes into _post_init after the ALTER. Regression test added; 119 store/route tests pass.

Cherry-pick to master: this bricks any controller that upgrades over an existing DB.

…MA (boot-brick)

The canvas and task stores put their element_id index in SCHEMA:
  CREATE INDEX ... ON project_canvas_elements(project_id, element_id)
  CREATE INDEX ... ON project_tasks(project_id, element_id)
BaseStore runs SCHEMA (executescript) BEFORE _post_init, so on an existing
pre-element_id database the index creation raised
'no such column: element_id' before the _post_init ALTER could add the column,
crashing controller boot after an upgrade. Reproduced live: the Pi bricked on
startup right after pulling this code (fresh installs were fine because SCHEMA
creates the table WITH element_id, so CI never exercised the migration path).

Move both indexes out of SCHEMA into _post_init, created after the ALTER.
Same class of bug and fix as the registry active-handle index (#1841).
Regression test seeds a pre-element_id DB and asserts both stores boot,
migrate the column, and build the index.
@qodo-code-review

Copy link
Copy Markdown

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

@coderabbitai

coderabbitai Bot commented Jul 16, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@jaylfc, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 22 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 5d955190-0b9a-456d-867b-6dbcdce56955

📥 Commits

Reviewing files that changed from the base of the PR and between 4c66986 and 5379911.

📒 Files selected for processing (3)
  • tests/projects/test_element_id_boot_migration.py
  • tinyagentos/projects/canvas/store.py
  • tinyagentos/projects/task_store.py
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch hotfix/canvas-task-index-boot-brick

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions

Copy link
Copy Markdown

👋 Thanks for the PR! This one targets master, which is our
stable branch (it's what live installs track). Please retarget it to
dev — click Edit next to the PR title and change the base
branch dropdown from master to dev. Your commits and any review
carry over, nothing is lost.

See CONTRIBUTING.md for the branch model.

@jaylfc
jaylfc merged commit fc01776 into master Jul 16, 2026
12 checks passed
@jaylfc
jaylfc deleted the hotfix/canvas-task-index-boot-brick branch July 16, 2026 17:32
@gitar-bot

gitar-bot Bot commented Jul 16, 2026

Copy link
Copy Markdown

Important

You are using the Gitar free plan. Upgrade to unlock code review, CI analysis, auto-apply, custom automations, and more.

Gitar

@kilo-code-bot

kilo-code-bot Bot commented Jul 16, 2026

Copy link
Copy Markdown

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (3 files)
  • tinyagentos/projects/canvas/store.py - moved idx_canvas_element index from SCHEMA into _post_init after the ALTER
  • tinyagentos/projects/task_store.py - moved idx_tasks_element index from SCHEMA into _post_init after the ALTER
  • tests/projects/test_element_id_boot_migration.py - regression test seeding a pre-element_id DB and asserting migration + index creation

Review notes: The fix correctly follows the BaseStore.init() contract (SCHEMA -> MIGRATIONS -> _post_init). Both indexes now use CREATE INDEX IF NOT EXISTS, which is idempotent and safe on fresh installs (column present from SCHEMA) and on legacy DBs (column added by the guarded ALTER in _post_init). The regression test exercises the exact boot-brick path that this PR fixes. No correctness, security, or logic defects found in the changed code.


Reviewed by hy3:free · Input: 39K · Output: 1.4K · Cached: 108.9K

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant