fix: prevent SQLiteBlobTooBig crash from oversized note body on app open

[MrLawrenceKwan]

Summary

Fixes the crash loop reported in #837 ().

Root cause

A legacy/imported oversized row can exceed CursorWindow limits during list reads (), causing Room LiveData query failures and making notes inaccessible.

Change (targeted)

• File changed:
• Added a Room callback that runs:

This is intentionally minimal and only touches rows above the existing app-defined size limit.

Why this helps

• Breaks the crash loop on startup/list loading
• Preserves accessibility to existing notes
• Uses existing max-body policy already enforced in app write paths

Notes

I could not run local Gradle compilation in this environment because Java runtime is unavailable ().
Code change is Kotlin-only, scoped to DB open safety repair.

Fixes #837

Summary by CodeRabbit

• Bug Fixes
  • Added an automatic data repair during upgrade that truncates note bodies exceeding the supported length, preventing errors from oversized content.
  • Database upgrade now includes this repair step so existing notes are corrected on first launch after updating, improving stability and data integrity.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

📝 Walkthrough

Walkthrough

Adds a Room database migration (v9 → v10) and bumps the database version to 10; the migration truncates any BaseNote.body values longer than BaseNoteDao.Companion.MAX_BODY_CHAR_LENGTH using SQL substr during the migration step.

Changes

Cohort / File(s)	Summary
Database Migration & Version app/src/main/java/com/philkes/notallyx/data/NotallyDatabase.kt	Bumps Room database version from 9 to 10, adds Migration10 to the migration list, and implements Migration10 to truncate BaseNote.body to MAX_BODY_CHAR_LENGTH via SQL substr during migration.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 I nibbled a note that was far too long,
A tumble of bytes that didn't belong.
With a careful trim and a hop and a cheer,
The database sings — the overflow's clear.
Tiny paws fixed what was needful and right. 🥕

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the fix: preventing SQLiteBlobTooBig crash from oversized note bodies, which directly matches the migration that truncates oversized body content.
Linked Issues check	✅ Passed	The changes implement the core requirement to repair oversized database rows by truncating BaseNote.body to MAX_BODY_CHAR_LENGTH via Migration10, directly addressing issue #837's crash and data accessibility.
Out of Scope Changes check	✅ Passed	All changes are narrowly scoped to the database migration: importing the MAX_BODY_CHAR_LENGTH constant, incrementing schema version, and adding Migration10 to truncate oversized rows—all directly related to fixing the reported crash.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/com/philkes/notallyx/data/NotallyDatabase.kt`:
- Around line 148-159: The onOpen repair in RoomDatabase.Callback (override fun
onOpen(db: SupportSQLiteDatabase)) currently runs a full-table truncation using
MAX_BODY_CHAR_LENGTH on every DB open and silently discards data; change this to
a one-shot operation (e.g., implement a Room Migration to a new schema version
or check/set a SharedPreferences flag before executing) so the UPDATE on
BaseNote only runs once, and before truncating: (1) identify affected rows and
persist their IDs/content elsewhere or set a truncated_flag column on BaseNote,
(2) emit a log entry or user-visible notification listing affected note IDs, and
(3) perform the actual substr(...) update only after backing up/persisting
overflow; reference the onOpen callback, MAX_BODY_CHAR_LENGTH, and the BaseNote
table when making these changes.

[MrLawrenceKwan]

Addressed latest review concern: moved the oversized-note repair from callback to a one-shot migration (, DB version 10).\n\nWhy:\n- avoids running full-table truncation on every DB open\n- performs the repair exactly once during schema upgrade\n\nPatch pushed in commit: b99be7f

[MrLawrenceKwan]

Follow-up correction: latest patch moves the oversized-note repair from database open callback to a one-shot schema migration (Migration10, version 9 -> 10). This ensures the UPDATE runs once during upgrade, not on every app open. Commit: b99be7f.

[lozzyactual]

Hi @MrLawrenceKwan,

Thank you. This looks promising but I am unable to compile things at this time to test it (I'm overseas, far away from my computer).

The app author has suggested that a the issue was addressed in 7.7.0 but updating to that manually has not fixed the error. There may be some peculiarity.

If I'm able to get your fix incorporated into a package I can install, I'm very interested to try it.

[lozzyactual]

Hey @MrLawrenceKwan,

The app author has created a hotfix which resolved the issue, and I've issued the bounty to him, but if you give me a PayPal or your osko deets (I'm also in Australia), I'd like to send you a little something just for your prompt efforts.

[MrLawrenceKwan]

Hey @lozzyactual — thank you, I really appreciate your kind offer 🙏

You can send via PayPal / PayID:
Kwanchingwai@gmail.com

Also, if you have any other app tasks (small fixes or larger features), I’d be happy to help.

Here are our Google Play app examples for reference:

1. Natural Beauty
   https://play.google.com/store/apps/details?id=com.electronhongkong.naturalbeauty

2. Kocomart ERP (Moment ERP)
   https://play.google.com/store/apps/details?id=com.electronhongkong.momentERP

We offer very affordable pricing (well below typical agency rates) with quick turnaround.
If you share 1–3 tasks, I can send a fixed quote and timeline right away.