Restored Mongo database write to original server when saving a workflow

[epilady]

I have restored a production gallery backup to a new alteryx server.  I followed all the steps outline and everything looks good on the surface.  The original gallery is x and the restored gallery is y.  In a designer session, I created a simple workflow to test indexing.  In designer I save as to gallery y, however the workflow appears on gallery x.  The base address in system settings points to gallery y.  Is there something embedded in the data base that is overriding the gallery destination?

[David-Carnes]

@epilady 

This is so weird.  I too have restored to a different, concurrent server and not had this problem.  Even with the Gallery names being the same, the Save As menu contains the URL underneath the Gallery name, thus preventing any confusion.

If this persists I recommend contacting Alteryx support.

Good luck!
David

[raychase]

@David-Carnes - somewhat related question, have you ever noticed that Alteryx Designer seems confused by concurrent Galleries that contain identical connections?  Since the underlying GUIDs associated with those Gallery connections are identical within each of their MongoDBs, Designer seems to treat them interchangeably.  I sometimes will see half of my connections under Gallery A and the rest under Gallery B.

This is especially problematic when you're saving a workflow to Gallery A, but the connection you happened to use is being associated with Gallery B.  In this case, I've found that the connection doesn't get properly included as a workflow asset.

[David-Carnes]

@raychase 
I have not had the pleasure of meeting that error.  When we got the Sandbox license I first used it to see if the weirdness that had crept into our MongoDB would go away with newer versions of Alteryx Server.   But it didn't, so I'm now using Sandbox to get us away from built-in authentication and move to integrated.

That behavior warrants either a support ticket or updating the ID of the data connections in the MongoDB.  (Me, I'd try the second one right after a restoration and if crashes then just restore over my mistakes.)

Good luck!

[raychase]

@David-Carnes 

Thanks for the reply. It surprises me that you wouldn't have run into this issue, assuming you are restoring a backup that contains Gallery connections and are configuring the controller token on the target machine to match that of the source machine.

Oddly, it isn't a given that the issue occurs with concurrent Galleries configured. If i manage my data connections and just spam the resync option, I can see connections flip flopping between which Gallery they belong to.

It makes me wonder how people leverage a QA to PD promotion process within their Alteryx Server environments. I can only assume that people are using two completely independent sets of Gallery connections, which sounds painful to manage.