Stale updates posted by iOS App

Please fill out the following sections to the best of your ability, it will help us investigate bugs if we have this information at the outset. Screenshots are especially helpful, so please provide those if you can.

Platform (Android, iOS, Website): iOS

App version number, if a mobile app issue (shown under Settings or About): 2.8.6, build 556 (note it is not in the About screen, but at the bottom of the Settings screen. The About screen has details about all the cocoapods.

Browser, if a website issue (Firefox, Chrome, etc) : n/a

URLs (aka web addresses) of any relevant observations or pages:

Screenshots of what you are seeing (instructions for taking a screenshot on computers and mobile devices: N/A

Description of problem (please provide a set of steps we can use to replicate the issue, and make as many as you need.):

Step 1: Create an observation on the web.

Step 2: Load the observation in the iOS app and attempt to suggest an ID. Either this times out or the app is backgrounded or killed before it completes.

Step 3: Suggest an ID on the web, using the same login as is used for step 2.

Step 4: After Step 3 (in the case of the linked observation, several hours later), open the iOS app.

Upon doing step 4, the app apparently wants to finish what it started, ignoring any more recent activity on the observation. This is a basic no-no of asynchronous updates. The first thing it should do when posting the update is to check if the record being updated is still at the same state it was when initiating the request. If not, it should be abandoned.

Note that I did NOT go into the observation on the app and enter the ID again and post an update. It was many hours previously that I did that, and the transaction didn’t complete, perhaps because there was some system update happening.

Here is a history of what happened with the observation, in order:

  • Observation was created. At the time it was created, the system was not letting me suggest an ID. So I posted the observation without and ID.
  • After the ID was posted, I tried entering an ID on the web. The system was not letting me. I presume that at this point the problem was with some system issue with the lookup of the suggested ID. Normally, when you enter a name, the system looks it up before it will take it. That is what was not happening.
  • Open iOS app and pull up the observation. Try entering an ID. This time the query seemed to work, and I thought I posted the update, but I may have closed the app before the posting completed.
  • Go to bed.
  • Some time overnight, jgw_atx suggested an ID.
  • After I got up, I confirmed that ID, then added a comment on the issue I was having.
  • Another comment and then I changed the ID because I didn’t like the one that was there (probably wrong).
  • I posted another ID, refining it to Culex tarsalis.
  • jgw_atx posts a comment.
  • About 7 hours later, I open the iOS app. Immediately, it acts like it’s updating an observation. After it completes, I open the observation, and it doesn’t have the above history (did not get a screen shot).
  • Refreshed using the pull to refresh and opened the observation again. Still no history.
  • Kill the app and start again, pull to refresh, still no history.
  • Log on to the web and undo the update that iOS did, and restore the good id, Culex tarsalis.
  • Create this post up to this point.
  • Open the app again and pull to refresh. Now the history shows.

So the essential part of the bug report is that a stale update should not overwrite a more recent update. That’s what happened here. A 7+ hour old request was able to overwrite more recent updates.

@victorengel It looks like you’re using an old version of the app, it was released just over a year ago. I recommend updating the app via the App Store (if you can - which version of iOS is your device running?).

Is what I described a bug that was fixed? I’ve just updated the app and now it shows 3.0.6 build 610. I can try to duplicate the scenario again, but it might be difficult if the server is responsive this time. :)

It’s possible it was fixed, but I don’t remember anyone reporting this particular bug. Version 3.0 is based on different underlying code from all previous versions, so comparing it to sub-3.0 versions isn’t really productive.

Either way, a fix would involve an update to the app, so it’s best to see if the current release still has the bug. I’d say don’t worry about replicating it again, but let us know if you come across it again.