> On Jul 27, 2017, at 1:34 PM, Jan Mulder <[email protected]> wrote: > > On 26-07-17 22:36, Jan Mulder wrote: >> On 26-07-17 20:35, Jan Mulder wrote: >>>> >>>> Mobile app session 2) >>>> >>>> - start a new mobile session >>>> - to my surprise, the credentials page is shown. Already filled in >>>> email/passwd and the "log shows loading dives from cache failed" >>>> - tried the save icon. Nothing happens >>>> - despite the credentials page still open on the page stack, I can >>>> navigate to the settings page. >>>> - On the settings page, I re-enter my passwd. >>>> - and exit the app. The session log is attached as subsurface-s-2.log, and >>>> does not contain anything relevant (so it seems to me) >> Well in another review ... a very suspicious line in subsurface-s-2.log: >> "requested dive list with credential status 119418". >> Allowed and valid values are 0-5 ... And as in session 1, the full >> (including pin) is fulfilled, session 2 should have started with valid >> credentials (value = 4). > > > And yes, I'm making some progress (all in git_access.cpp). All in the use > case: initial creation of a cloud account from mobile. > > 1) due to commit 9367613a77ec62 (1.5 years old ...), the local repo is not > created. Not sure what the right way on is here (yet). > > 2) strangely (as the strstr() compare is case sensitive), at line 741 will > never result in execution of create_and_push_remote(). The git line starts > with "reference" and not "Reference". > > 3) The main reason (I now believe) that I run in to these issues is that I am > following a path trough the code that seemingly never really has been used. > Before, the cloud was setup on desktop, and on mobile only the already valid > cloud stuff needed to be filled in. There seems to be some timing issue. > Initial account creation works fine, but the initial connect with the just > created new account always fails. The server appears not have finished the > setup of the new account. It might be an idea to send the "VERIFIED" message > after successful creation of the repo on server side (obviously, I do not > know what the server actually does).
The server code was written by an incompetent moron in tiny increments with insufficient testing and whenever something happened to work for a test case development ceased until the next thing blew up. In my infinite spare time I plan to turn that into an amazing open source project... Let me look (not sure when, though) into delaying the VERIFIED message until I'm 100% sure that the next request would succeed. Thanks for your investigative work on this!!! /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
