The mojo version of LocalStorage relies heavily on relative ordering of messages it receives via the LevelDBObserver interface and messages it receives as replies to messages send on the LevelDBWrapper interface.
Currently however these two connections are completely separate, made over independent pipes. Two possible solutions I can see:
1) Change StoragePartitionService.OpenLocalStorage to pass both interfaces as associated interfaces. That way both will share the pipe with StoragePartitionService, and the expected ordering works outfine, or
2) Change how observers are added, by adding an AddObserver(associated LevelDBObserver observer); method to LevelDBWrapper (and removing the observer from the OpenLocalStorage call), or
3) Somehow rework the logic in LocalStorageCachedArea to not rely on relative ordering of observed events and async replies. Sort of possible: every async reply already sort of has a matching observable event, and we have the "source" blob we could extend with more random/sequential request IDs to try to match method calls with observed events. But tricky to get right, and needing request ids in the first place is something mojo is supposed to help us get rid of, so adding more of them feels going the wrong way.
Not sure what the best approach is going to be, but 1 and 2 aren't too different in practice.
Somewhat related, the GetAllCompleted with its randomly generated request id that than is matched against feels really icky to me... I wonder if a neater solution would be to get rid of the "source" for GetAll and instead pass an (associated) interface whose sole purpose is to be notified when GetAll is completed. That would at least get rid of the random request ID masqueraded as a string. But well, that's a whole different story, unrelated to this bug.
Comment 1 by bugdroid1@chromium.org
, Dec 21 2016