Possible issue with OTA restore

Hello all,

We are planning to use the OTA restore functionality in CommCare for our
project and we have uncovered what we believe to be a problem with the Case
XML being returned by CommCare HQ during a restore. It seems that the OTA
restore Case XML is not reflecting the changes made to a case after the
original client registration. This is probably best explained via an
example. Our CommCare app has several forms, the three most common forms
are a client registration form (run once per client), a follow-up form (run
n times per client), and a closing form (run once per client). When you
submit a new client to CommCare HQ, after completing the registration form,
and then do a OTA restore the Case XML restores perfectly. If you then
complete the follow-up form, submit to CommCare HQ, and then do a restore,
the changes you made to Case XML (in the Case XML element) do not
appear in the OTA restore. Similarly, if you try to close a case, using the
closing form, the fact that the case is closed is not restored OTA. I can
check the contents of the OTA restore by visiting
http://dev.commcarehq.org/ota_restore and entering our credentials. Indeed,
the Cases appear frozen in their original state from when I first submitted
the client registration form.

If I never do an OTA restore and just keep adding clients, doing follow-ups,
and closing cases, everything works perfectly. It’s when I do an OTA
restore that we loose the Case updates from the follow-up and closing forms.

Interestingly, referrals do not seem to experience the same problem. These
seem to restore perfectly and in the correct state.

I wanted to make sure it wasn’t just our app that would have this problem,
so I compiled the pathfinder app and ran through the same process. Indeed,
this behavior is replicated in pathfinder, as well.

I was mostly wanted to verify that this is not expected behavior. I know
that CommCare HQ 1.0 is almost here and perhaps this is addressed in this
release.

Best,
Stephen

Hi Stephen,

··· On Tue, Feb 8, 2011 at 10:24 AM, Stephen Lorenz wrote: > I was mostly wanted to verify that this is not expected behavior. I know > that CommCare HQ 1.0 is almost here and perhaps this is addressed in this > release.

This is most definitely not the expected behavior, and should
definitely not be observed in 1.0. Our 0.9 server logs indicate some
problems generating the OTA restore payload that I imagine are related
to the issue you’ve observed. Since we are quickly phasing out the 0.9
codebase, just wanted to confirm that you can wait until the 1.0
release for a proper fix.

Thanks for bringing this to our attention!

Cory

Hi Cory,

Thanks for the update. I’m glad that it should be fixed in 1.0. If I
understand the schedule for the roll out of 1.0 (next 1-2 weeks) we should
be able to wait.

Thanks!
Stephen

··· On Tue, Feb 8, 2011 at 12:16 PM, Cory Zue wrote:

Hi Stephen,

On Tue, Feb 8, 2011 at 10:24 AM, Stephen Lorenz stephen.lorenz@gmail.com wrote:

I was mostly wanted to verify that this is not expected behavior. I know
that CommCare HQ 1.0 is almost here and perhaps this is addressed in this
release.

This is most definitely not the expected behavior, and should
definitely not be observed in 1.0. Our 0.9 server logs indicate some
problems generating the OTA restore payload that I imagine are related
to the issue you’ve observed. Since we are quickly phasing out the 0.9
codebase, just wanted to confirm that you can wait until the 1.0
release for a proper fix.

Thanks for bringing this to our attention!

Cory