Tencent / MMKV

An efficient, small mobile key-value storage framework developed by WeChat. Works on Android, iOS, macOS, Windows, and POSIX.
Other
17.28k stars 1.9k forks source link

Could adding a trim() method result in incorrect data state? #1237

Closed vellrya closed 6 months ago

vellrya commented 6 months ago

The language of MMKV

Kotlin

The version of MMKV

v1.3.3

The platform of MMKV

Android

The installation of MMKV

Gradle

What's the issue?

Hello.

I have been using MMKV with no problems in multiprocessing mode, however I found that the data file can grow to a significant size, so I added a call to trim() in onCreate and updated library to 1.3.3.

After installing the new version of the application, several users reported strange things about the application, I checked the logs and found out the following: After one of the application launches, the preference is cleared and the in-app initial setup process starts. But the strange thing is that on the next launch (but I can't say 100% that there were no intermediate launches) the app "remembers" old data that was saved about a few weeks before the reset.

I store and log changes of the server-side configuration, it looks something like this: 05.01.23: onCreate -> update cfg from 0 to 9 //load current server cfg ver after first install 08.01.23: onCreate -> update cfg from 9 to 10 10.01.23: onCreate -> update cfg from 10 to 11 20.01.23: onCreate -> update cfg from 11 to 12 25.02.23 10:00: onCreate -> update cfg from 0 to 12 //preference lost, load current server cfg 25.02.23 11:00: onCreate -> update cfg from 10 to 12 //did the app somehow recover the old data, but not the data that was there before it was lost?

I am running the library initialisation in onCreate for the main and background process in an identical way:

MMKV.initialize(this, File(ContextCompat.getDataDir(INSTANCE.applicationContext), "databases").absolutePath)
preferences = MMKV.mmkvWithID("APPKV", MMKV.MULTI_PROCESS_MODE)
preferences.trim()

I can't completely rule out the possibility of data modification by root users, but I don't see how that would be an advantage, or why several different users reporting the bug would categorically deny doing a restore from backup or anything like that.

Is there a possible bug on the MMKV side that has to do with adding a .trim() call or updating the library version? Maybe the reason is the simultaneous call of .trim() in the main and background process, should I leave this method only in the main process? I would be grateful if you could help me figure out the cause of the problem.

P.S. I should clarify that everything works correctly for most users, I was not able to reproduce the error on my device either.

lingol commented 6 months ago

You should provide logs of MMKV both before & after it happens.

vellrya commented 6 months ago

Unfortunately, I don't have such logs. I hoped that it would be possible to find out the cause of the error by the changes made: a call to the trim() method was added and the MMKV version was updated from 1.3.2 to 1.3.3. The beta version of my application with these changes is installed on approximately 1000 devices, the error was reported by 3 users with different device models. I do not exclude that there may be more such cases, but not all users have reported this error.

lingol commented 6 months ago

Unfortunately, I don't have such logs.

Well, you should. Otherwise, it'll only be guessing and taking chances.

lingol commented 6 months ago

It's protected with v1.3.4.