ADFA-2692 | Fix storage accessibility error reporting

[jatezzz]

Description

Implemented a self-healing mechanism in AssetsInstallationHelper that attempts to create the installation root directory if it is missing. This resolves potential race conditions during fresh installations where the directory might not be ready yet.

Additionally, added a flag to Result.Failure to suppress Sentry reporting for "Storage not accessible" errors. These errors are often environmental (e.g., device locked, permissions denied) rather than application bugs, so they shouldn't clutter the crash logs.

Details

Logic update:

• Added shouldReportToSentry to Result.Failure.
• checkStorageAccessibility now attempts mkdirs() before failing.
• InstallationViewModel checks the flag before capturing exceptions.

Before changes (race condition)

Screen.Recording.2026-01-30.at.5.00.13.PM.mov

After changes

Screen.Recording.2026-01-30.at.5.02.29.PM.mov

Ticket

ADFA-2692

Observation

The "Storage is not accessible" error will now only appear if the app explicitly lacks write permissions (or the device is encrypted/locked), but it won't be reported to Sentry. If the folder is simply missing, the app will recreate it and proceed.

[coderabbitai]

Caution

Review failed

The pull request is closed.

📝 Walkthrough

Release Notes: ADFA-2692 | Fix storage accessibility error reporting

Changes

• Self-healing storage mechanism: Added automatic directory creation in checkStorageAccessibility() which attempts to create the installation root directory using mkdirs() if missing, addressing race conditions during fresh installations.
• Selective Sentry error reporting: Introduced shouldReportToSentry flag (default true) on Result.Failure data class to allow selective suppression of Sentry error logging for storage accessibility failures.
• Updated error handling: InstallationViewModel now respects the shouldReportToSentry flag before capturing exceptions to Sentry, reducing noise from environmental storage errors.

Behavioral Improvements

• Missing installation directories are automatically recreated; app proceeds without Sentry reporting if recovery is successful
• "Storage not accessible" errors from environmental causes (e.g., device locked, permissions denied) are no longer logged to Sentry
• Storage accessibility checks now occur with recovery attempts rather than immediate failure

⚠️ Risks & Best Practice Concerns

1. Incomplete race condition mitigation: The mkdirs() attempt improves reliability but does not fully eliminate race conditions. The directory could be deleted or become inaccessible between the check and actual file operations. Consider additional synchronization or retries if concurrent access is possible.

2. Silent failure handling: Failed mkdirs() attempts are logged only as warnings and silently swallowed. If directory creation fails for reasons other than existence (e.g., permission issues), the app will still fail later without clear diagnostics.

3. Scattered error reporting logic: Error suppression decisions are now split between the Result.Failure object and InstallationViewModel. This could complicate future maintenance if additional error types require conditional reporting.

4. Asymmetric default behavior: While shouldReportToSentry defaults to true, only storage errors explicitly set it to false. If other failure types should also suppress reporting, this pattern should be revisited to avoid inconsistency.

5. Potential over-suppression: Storage errors that indicate serious issues (e.g., corruption, permission denial) may be missed in monitoring if they are all suppressed from Sentry.

Walkthrough

Adds a shouldReportToSentry flag to installation failure results, makes Sentry reporting conditional on that flag, and attempts to create the storage root directory (mkdirs) during accessibility checks; storage-accessibility failures are returned with shouldReportToSentry = false.

Changes

Cohort / File(s)	Summary
Assets Installation Helper app/src/main/java/com/itsaky/androidide/assets/AssetsInstallationHelper.kt	Added shouldReportToSentry: Boolean = true to Result.Failure. Attempt root.mkdirs() (wrapped in runCatching) when checking storage accessibility; return storage-accessibility failures with shouldReportToSentry = false.
Installation ViewModel app/src/main/java/com/itsaky/androidide/viewmodel/InstallationViewModel.kt	Only call Sentry.captureException when result.shouldReportToSentry is true; other failure handling (error event emission, state update) unchanged.

Sequence Diagram(s)

sequenceDiagram
autonumber
participant VM as InstallationViewModel
participant Helper as AssetsInstallationHelper
participant FS as Filesystem
participant Sentry as Sentry
VM->>Helper: start assets installation
Helper->>FS: check storage accessibility (exists? -> attempt mkdirs())
alt mkdirs/create failed
FS-->>Helper: failure (reason)
Helper-->>VM: Result.Failure(shouldReportToSentry=false, error)
else accessible or created
FS-->>Helper: success
Helper-->>VM: Result.Success
end
alt result is Failure and shouldReportToSentry == true
VM->>Sentry: Sentry.captureException(error)
else result is Failure and shouldReportToSentry == false
VM-->>VM: handle failure without reporting
end

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• ADFA-2692 | Fix storage accessibility error reporting #910: Makes the same code-level changes—adds shouldReportToSentry, conditions Sentry reporting, and attempts mkdirs() in storage checks.
• ADFA-2206: Fix NPE in asset installation when zip entry is missing #699: Modifies the same Result.Failure data class and adjusts failure reporting in the viewmodel.

Suggested reviewers

• itsaky-adfa
• alome007
• jomen-adfa

Poem

🐇 I dug a little folder, neat and sound,
I tried to build it up from ground.
Quiet bugs I tuck away, not sent to see,
Loud ones I whisper to Sentry.
Hop, install, and code with glee. ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 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 (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: implementing a fix for storage accessibility error reporting, which aligns with the PR's primary objective of adding selective Sentry suppression.
Description check	✅ Passed	The description is well-detailed and directly related to the changeset, explaining the self-healing mechanism, shouldReportToSentry flag, implementation details, and behavioral implications.

_{✏️ 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
• Commit unit tests in branch fix/ADFA-2692-storage-accessibility-error

---

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.}