2.1.0.1 sequential number resets back to 0000 within a user

Question

2.1.0.1 sequential number resets back to 0000 within a user

eyarzebinski opened this issue 6 years ago · comments

The following json files were generated from the same user/tablet (6105001158) in pretty rapid succession. Note that the sequence resets back to 0000 a few times, which is unexpected behavior. The sequencer should be unique per tablet.

PERF_RoboTutor_release_dbg.2.1.0.1_2018.09.03.11.08.08_6105001158_0000
PERF_RoboTutor_release_dbg.2.1.0.1_2018.09.03.11.12.29_6105001158_0001
PERF_RoboTutor_release_dbg.2.1.0.1_2018.09.03.11.42.15_6105001158_0002
PERF_RoboTutor_release_dbg.2.1.0.1_2018.09.03.11.43.37_6105001158_0000 <- repeats sequence
PERF_RoboTutor_release_dbg.2.1.0.1_2018.09.03.15.00.54_6105001158_0001 <- repeats sequence
PERF_RoboTutor_release_dbg.2.1.0.1_2018.09.03.15.06.24_6105001158_0000 <- repeats sequence
PERF_RoboTutor_release_dbg.2.1.0.1_2018.09.03.15.24.22_6105001158_0001 <- repeats sequence
PERF_RoboTutor_release_dbg.2.1.0.1_2018.09.03.16.28.53_6105001158_0002 <- repeats sequence
PERF_RoboTutor_release_dbg.2.1.0.1_2018.09.03.16.29.45_6105001158_0003
PERF_RoboTutor_release_dbg.2.1.0.1_2018.09.04.13.51.57_6105001158_0000 <- repeats sequence

@ealanhill or @kevindeland (not sure which of you has more time at the moment...) can you please look into this? Thanks!

JackMostow · Answer 1 · Wed Sep 05 2018 23:21:56 GMT+0800 (China Standard Time)

According to Who has which tablet(s), 6105001158 is... drum roll, please... let's see... me! I did reinstall 2.1.0.1 a few times, which I assume is the explanation.

eyarzebinski · Answer 2 · Wed Sep 05 2018 23:30:59 GMT+0800 (China Standard Time)

Ah interesting. So that means any new install will restart at 0000 because all of the prior json files will be wiped out? In general I guess that's fine because that means there's a relative order within each version, but if there is a reinstall of an existing version for any reason this will render the sequence meaningless for that tablet.

JackMostow · Answer 3 · Thu Sep 06 2018 01:06:44 GMT+0800 (China Standard Time)

A reinstall apparently restarts at 0000, but not because prior json log files are deleted -- they aren't.
Some other mechanism must keep track of numbering -- presumably the OS persistent storage mechanism.
@kevindeland - Please increase log numbering to, say, 6 digits rather than 4 -- unless I'm crazy to worry about having >10,000 sessions on a tablet.

eyarzebinski · Answer 4 · Thu Sep 06 2018 02:52:07 GMT+0800 (China Standard Time)

Hm. If the same version is reinstalled on a given tablet, the sequence should not restart at 0000 (or 000000). If a new version is installed, I'm fine with it either continuing to increment or starting back at 0.

JackMostow · Answer 5 · Thu Sep 06 2018 03:31:56 GMT+0800 (China Standard Time)

I don't know, but I'd guess that:

Installing RoboTutor declares and initializes a variable stored in the OS's persistent storage. If it's possible to check first if it already exists and if so just increment it, numbering could continue after install.
Uninstalling RoboTutor deallocates this variable. If so, numbering cannot continue after uninstall.

eyarzebinski · Answer 6 · Thu Sep 06 2018 19:35:32 GMT+0800 (China Standard Time)

@kevindeland or @ealanhill - to summarize the last few comments, please increase the sequence to 6 digits (I agree with Jack that 4 is most likely not enough), and please confirm the expected behavior within and across version numbers in the case of uninstalls and also reinstalls. How soon can this be done? Would be good to get any updates in the next QA cycle for a stress test.

Alan Hill · Answer 7 · Fri Sep 07 2018 10:20:16 GMT+0800 (China Standard Time)

How likely is it that someone will reinstall the same version out in the field? Is this just a QA concern? Or an end user concern?

JackMostow · Answer 8 · Fri Sep 07 2018 12:06:40 GMT+0800 (China Standard Time)

Not likely at XPRIZE sites, because it does installs at a central facility and deploys new versions at its sites by swapping out tablets. Likeliest in-house or at our beta sites.

eyarzebinski · Answer 9 · Fri Sep 07 2018 22:15:09 GMT+0800 (China Standard Time)

I'm not sure how likely a reinstall is. However, if possible I would like to avoid having the sequence be meaningful for only some tablets.

Kevin DeLand · Answer 10 · Sat Sep 08 2018 03:36:52 GMT+0800 (China Standard Time)

It is possibly relevant for beta-testing but not for the XPrize data, as XPrize APKs will only be installed once.

Alan Hill · Answer 11 · Wed Sep 12 2018 02:55:55 GMT+0800 (China Standard Time)

@eyarzebinski can you provide some more log file names? the ones originally provided in this one seem incorrect (that is, not what I set up nor what I see with my local logs).

Alan Hill · Answer 12 · Wed Sep 12 2018 02:59:04 GMT+0800 (China Standard Time)

I don't know how much effort should be put into trying to continually keep the sequence IDs in sync.

Part of the solution would be more permanent storage that doesn't seem to be in place at the moment. Or scanning ALL the log file names, parsing them, then increasing the sequence ID. This would take time on start-up and time to implement.

So, I don't know if it would be the best use of time to implement for a QA only item at this time?

eyarzebinski · Answer 13 · Wed Sep 12 2018 21:35:14 GMT+0800 (China Standard Time)

@ealanhill sure - here's some more json files that I see have been synced to Drive in the last few days as team members test the new tutors in QA:

PERF_RoboTutor_release_dbg.2.1.0.1_2018.09.06.22.37.18_6105001158_0014.json
PERF_RoboTutor_release_dbg.2.1.0.1_2018.09.07.15.04.36_6105001158_0015.json
PERF_RoboTutor_release_dbg.2.1.0.1_2018.09.07.15.14.34_6105001158_0016.json

and from a different tablet...

PERF_RoboTutor_release_dbg.2.1.0.1_2018.09.05.09.35.49_6111000112_0003.json
PERF_RoboTutor_release_dbg.2.1.0.1_2018.09.05.09.56.33_6111000112_0004.json

You mention these seem incorrect - can you share what they look like on your end?

JackMostow · Answer 14 · Thu Sep 13 2018 01:56:58 GMT+0800 (China Standard Time)

@ealanhill - Making sequence number survive reinstallation of the same-named version is worth very little if any effort. If there's a quick fix, fine; otherwise forget it. Thanks. - Jack

Alan Hill · Answer 15 · Thu Sep 13 2018 05:18:25 GMT+0800 (China Standard Time)

@eyarzebinski Hmm that is definitely not the format I was hoping to send you. The should look something like this:

PERF_RoboTutor_debug.2.1.0.1_00000_2018.09.11.09.52.19_unknown.json
PERF_RoboTutor_debug.2.1.0.1_00001_2018.09.11.09.52.45_unknown.json

or

RoboTutor_debug.2.1.0.1_00000_2018.09.11.09.52.19_unknown.json
RoboTutor_debug.2.1.0.1_00004_2018.09.11.10.14.54_unknown.json

(note: the unknown is because I used an emulator to get these files)

I'm not sure, but @kevindeland is there another place in the code that generates a log file?

@JackMostow ok, if I come up with something quick I'll update the app.

Kevin DeLand · Answer 16 · Thu Sep 13 2018 06:28:01 GMT+0800 (China Standard Time)

@ealanhill for reference, I modified the log file format slightly to make the log filename look more like the old format. It's just the old format, with the number on the end.

See this commit

eyarzebinski · Answer 17 · Thu Sep 13 2018 20:51:00 GMT+0800 (China Standard Time)

thanks @ealanhill and @kevindeland - I'm fine with the number in either place, the only implication of that for me is updating my parsing/cleaning code differently depending on where it ends up.

JackMostow · Answer 18 · Fri Sep 14 2018 20:44:31 GMT+0800 (China Standard Time)

We want sorting logs by name to put them in chronological order even when the timestamp is bogus, so please name them as APK name + tablet ID + sequence number + ...