Improve versioning stability about codecombat HOT 9 OPEN

Though mongodb uses the term two phase commits, it is not exactly two atomic operations that are happening, and this is the reason for its complexity.

From the two proposed solutions, implementing two phase commits is the better option. Coding is not the challenging part, figuring out a sequence of steps and recovery procedures is. I can attempt this. Is there anyone else working on it?

The directory structure must have changed during refactoring. There is no /server/models folder anymore. Where has that been moved to?

from codecombat.

The plugins file is probably what you're looking for. makeNewMinorVersion and makeNewMajorVersion

There is a cooler alternative though: #264

from codecombat.

The gist alternative is actually two phase commits in a different form. Commit a new version as the code, and switch to using the new version, being the two phases. But this has to be handled differently, since gists always go forward in the commit chain, we will have to apply a revert commit to do the first phase rollback, in case the second phase fails.

Coming to think of it, we don't actually need a external service like gists to handle this. If the logic that locates the newest versioned document is separated from the part that saves a new version of document, we can do it all using the existing database itself.

The main cause of this problem is that the code that makes a new version also clears a flag on the existing latest document that says it is latest. Simply refactoring to make this change happen last in the pipeline, after the newer version is saved, should get rid of this bug.

from codecombat.

Note that we have a DB index that prevents there being more than one document in the db with the same:

https://github.com/codecombat/codecombat/blob/master/server/plugins/plugins.coffee#L125

So simply reversing will come into conflict with that index. The second solution gets around this by just 'moving' the existing document to its new version then creating the old version again.

from codecombat.

I will explain in more detail. From my understanding,

• There is a flag on the document that indicates if it is the latest version
• This flag is being unset while a new version is being created, but before the new version is saved.
• The new version gets gets the flag set while being saved.

The problem is, what if the save fails? We have no document with the flag set. Proposed solution:

• Defer unsetting the flag until the new version is saved.
• Save the new version with the flag initially unset.
• Reverse the flags now.

This modification in the workflow requires protecting only a single, simple change using a guard of some sort. If a simple error callback doesn't cut it, we can have two phased commit. But at this point, the logic is more clear to follow, and simpler to implement.

So this will not conflict with the index.

from codecombat.

@sderickson Do we still need this thing? It seems like it hasn't been causing any problems, but I could be wrong.

from codecombat.

Ah just saw what might have been this one when Valentin was trying to rename a level; lost its isLatestMajor version and slug while keeping its isLatestMinor version.

from codecombat.

Saw it again. Had a level "Elf If", renamed it to "Munchkin Mania", tried to save and it gave me a "name already in use" noty error. Renamed it to "Maniac Munchkins", saved, page reloaded, redirected me to elf-if again. Artisans channel says Maniac Munchkins. Going to maniac-munchkins or elf-if gives 404s

Had to get Nick to unstick it.

from codecombat.

Example code on how to fix it in MongoShell:

var level = db.levels.findOne({name: 'Breaking and Entry222'})
level.slug = 'breaking-and-entry222'
level.version.isLatestMajor = true
db.levels.save(level)

from codecombat.