01:36 <zarvox> Grrrrr. Alpha appears to have lost its login providers.

01:36 <zarvox> And it's probably my migration scripts' fault.

01:38 <zarvox> kentonv: if you could do the admin-token flow to reenable google/github login, that would be great. Consider taking a dump of the associated collections (settings & the specific oauth providers), since based on the information I was working with, and the tests I ran, this should not have happened.

01:40 <zarvox> I suppose I should have asked for access to an actual real config DB that was in this state, or set up an older version of Sandstorm, rather than going on what I was told that DB should look like.

02:15 <dwrensha> zarvox: I'm about to update my server with your migrations change

02:15 <dwrensha> any particular state you'd like to observe?

02:15 <dwrensha> db.settings ?

02:21 <dwrensha> yep, so after the update I'm seeing "No login services configured"

02:26 <dwrensha> ... and it looks like db.settings and db.meteor_accounts_loginServiceConfiguration were not changed in the migration

02:27 <zarvox> dwrensha: so in db.settings, what are the values for github and google?

02:27 <dwrensha> { "_id" : "github", "value" : true }

02:27 <dwrensha> { "_id" : "google", "value" : false }

02:28 <zarvox> okay, that much is as expected, assuming you explicitly configured github OAuth

02:28 <zarvox> and didn't configure google oauth, or did, but then explicitly disabled it

02:29 <zarvox> FWIW, kenton says the problem is in the accounts-oauth package

02:29 <dwrensha> is the problem that the Settings collection isn't reaching the client side?

02:30 <dwrensha> From the "admin" publish, it looks only admin users get to see Settings

02:30 <zarvox> Could be, he didn't elaborate.

02:31 <zarvox> Ahhh, that could explain why everything worked great in testing - I was an admin user there.

02:31 <dwrensha> the thing I'm talking about is in admin.js, not the accounts-oauth package

02:36 <zarvox> Technically, it's not the value in db.settings that matters, it's whether the ServiceConfiguration is registered with meteor accounts

02:38 <zarvox> theoretically, *that* should be reactive on the value in db.settings, but I guess if that's frontend-driven, then it can't see the settings?

02:38 <kentonv> pushing fix now

02:39 <kentonv> migrations weren't the problem. The list of enabled oauth services was not reactive, so if the subscription arrived after the template rendered you'd be hosed

02:39 <kentonv> the subscription which populated the list, that is

02:42 <kentonv> whoops, release script didn't like the fact that I manually reverted the current published version... trying again

02:45 <kentonv> all better

03:04 <zarvox> Thanks! Now if we're lucky, we're about the only ones that noticed the bug ;)