Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lost the app_settings, presumably during a failed kujua-lite update #386

Closed
abbyad opened this issue Oct 7, 2013 · 7 comments
Closed

Lost the app_settings, presumably during a failed kujua-lite update #386

abbyad opened this issue Oct 7, 2013 · 7 comments
Labels
Type: Bug Fix something that isn't working as intended Won't fix: Ancient Too old to investigate

Comments

@abbyad
Copy link
Contributor

abbyad commented Oct 7, 2013

History of issue for posterity:

  • This was a manually pushed instance that eventually got to 0.3.0-beta.9 using dashboard's update.
  • Could not update using Dashboard due to version numbering bug, so updated Dashboard from 10.5 to 10.6
  • Update button now showed for KL in Dashboard, clicked it but don't recall if it said "Finished".
  • KL still shows 0.3.0-beta.9
  • Contents of app_settings disappeared, as seen between revs 34 & 35
@abbyad
Copy link
Contributor Author

abbyad commented Oct 7, 2013

Some further info after restoring the app settings and updating to KL 0.3.0-beta.13

The update process caused the ddoc to be incremented twice - from 39 to 41

Interestingly, the app_settings in rev 40 is blank.... which seems to indicate that a failed update can leave KL without its app settings.

@mandric
Copy link
Contributor

mandric commented Oct 7, 2013

Well you would still be left with the app_settings on the previous revision (39). The update process replicates the new ddoc in and then updates the app_settings property based on the previous revision. The right thing to do in case of failing to update the app_setting property is to revert the ddoc update (in this case back to revision 39).

@ghost
Copy link

ghost commented Oct 7, 2013

Is it updating twice here?

@mandric
Copy link
Contributor

mandric commented Oct 9, 2013

Pretty sure it is, by design. Once to replicate the new ddoc, once to update the app_settings property. I don't see anything wrong with that per se, except for better error handling. BTW, this is a dashboard issue and we should probably open an issue there if we want it changed... https://github.com/garden20/dashboard

@ghost
Copy link

ghost commented Oct 9, 2013

I'm trying to think if we could solve these sorts of conflict issues generically, perhaps inside of a form renderer. There are similar failures (but not data-loss issues) when multiple updates to the same user happen in _rewrite/users.

Dave

@mandric
Copy link
Contributor

mandric commented Oct 9, 2013

I'm not sure if that's the same issue. But what might help is to serialize the ajax calls per UI so one ajax async call doesn't overwrite another? Maybe something like https://github.com/gnarf/jquery-ajaxQueue.

@mandric
Copy link
Contributor

mandric commented Oct 9, 2013

Also just looked at the dashboard issue tracker and found this item garden20/dashboard#42

So I think this also describes the problem of not being able to update after manually pushing, I think that is a pretty important one too. We should probably add some comments there to upvote if we thinks it's important to fix. I would argue it's probably more important than this issue (app_settings update error handling or supporting revert).

@ghost ghost added the Won't fix: Ancient Too old to investigate label Nov 25, 2014
@ghost ghost closed this as completed Nov 25, 2014
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug Fix something that isn't working as intended Won't fix: Ancient Too old to investigate
Projects
None yet
Development

No branches or pull requests

2 participants