Feature - #551 - Clearing History Via Isolate

[Vishwa-Karthik]

Foss Hack 2025 - Clear History Via Isolate

Use of dynamic switch logic to determine the use of [Compute] function and [Isolate] function to Clear History during the app launch.

Team Dart Knight

• User - Vishwa Karthik
• Mail - [email protected]

Relevant PR for Clearing API History

• PR 1 - Simple Base Mechanism
• PR 2 - Enhancement & Dynamic Trigger Mechanism

Debug Considerations

• Enrolled new enum value of 5second for HistoryRentetionPeriod for debugging purposes.
• The final PR will have clean code

Checklist

• [✅] I have gone through the contributing guide
• [✅] I have updated my branch and synced it with project main branch before making this PR
• [✅] I am using the latest Flutter stable branch (run flutter upgrade and verify)
• [✅] I have run the tests (flutter test) and all tests are passing

Added/updated tests?

We encourage you to add relevant test cases.

• Yes
• No, and this is why: will complete once the approach is confirmed as correct

OS on which you have developed and tested the feature?

• [✅] Android
• [✅] Windows
• macOS
• Linux

cc: @ashitaprasad

[ashitaprasad]

Let me know when this PR is ready for review.

[Vishwa-Karthik]

My Findings...

Local Database Hive do not support concurrent connections or transactions due to Native OS locking the hive files on the user desired directory, (hive.lock) files.

• Linux Based Arch Distributions and Apple System follow strict file lock system and wouldn't allow opening or accessing boxes from multiple isolates.

Reasoning

• Hive.init and hive.initFlutter are both method-channel and main UI thread operations which needs many data accessibility which are only available in main thread isolate.

Cheap Work Around Solution

1. Close Hive in the main thread
2. Start an isolate
3. Initialize Hive in that isolate
4. Offload tasks to new isolate & Close Hive
5. Re-Open Hive Box in the main thread

Problems

• Although the database transactions are fast, there are high chances the database behavior becomes highly unpredictable.
• The cleaning service job trigger logic had to changed, since calling it main function may become stupidity.

Technical Issues

• With issues stated, frequent switches between threads will make too many open/close hive boxes to hinder performance of the app.
• App may stop working abruptly
• IOS Production app may not allow these operations to do so, and may kill the app.
• The Hive documentation clearly states that it is not designed for multi-threaded use.
• Simultaneous reads/writes across isolates may lead to inconsistencies.

What about... PR 604

• The reason why it could have worked for Android, is due to its lenient OS behavior although its Linux-based distribution.
• Even though Android doesn't throw an error, it's still not safe to open Hive in multiple isolates.

Note

• There is another database called 'Isar' which probably supports multi-threaded concurrent transactions which could have been possible to resolve this functionality.

Conclusion

• The issue opened is very real but the way it has to be tackled is just to clear them in main isolate using optimization techniques like batch request, clearing history in frequent intervals and few more everything in Main Thread ONLY.

cc: @ashitaprasad

[ashitaprasad]

To be reviewed by @DenserMeerkat

[DenserMeerkat]

@ashitaprasad
The stated alternate solution works 👍, but I couldn't find a way to check & compare performance differences with the batching.
I believe the 5 seconds retention period can be removed and the PR title can be renamed to match the solution used.