No Postgres clusters in your organization

[moishinetzer]

CLI says no managed postgres clusters found in organization

I am looking at a managed Postgres cluster under my personal organization that is up and running the green glowing dot and everything pooling enabled. It’s even creating a backup. However, when I run ‘fly mpg connect’, I get an error saying there’s no Postgres clusters in my organization.

This is STILL an issue. Will this be resolved?

[jphenow]

Hey can you fly auth logout and fly auth login?

[moishinetzer]

This was what solved my issue however it took me time to find. Is there interest in fixing the root cause?

[jphenow]

The root is that we’re using better tokens now and there’s not a stellar way to upgrade them in place without causing different issues for people. We will update the CLI to make that more apparent when we detect it especially for commands like mpg that require it.

reauthing isn’t something you should have to do to fix this periodically, fwiw. It’s just something that gets your local machine off the older style of tokens.

[moishinetzer]

That’s a fair callout. I’d prefer to be booted out and forced to reauth in this case as being told there are no mpg instances when there clearly are is a really odd CX.

Thanks for being responsive on this!

I’d also like to note that I’m loving having mpg around it’s an incredible product.

[lillian]

@moishinetzer

I’d prefer to be booted out and forced to reauth

the problem is that people running CI jobs who have an existing token would not prefer to be unexpectedly logged out and have to go update their CI job secrets.

thanks for the reminder though. we will add a clearer error message here, and a legacy token warning across the client.

[moishinetzer]

the problem is that people running CI jobs who have an existing token would not prefer to be unexpectedly logged out and have to go update their CI job secrets.

Customers running mpg on CI with an old token should need a new job secret if their intention is to use this API? Same goes for any other cli actions that will require a new token or behave in unexpected ways, it would be better to catch it at CI failure and rotate to a new token than have unexpected prod behaviour. If this is the case I think it’s a strong case to force reauth when new tokens are required.

[lillian]

ah, I was referring to doing things that are not MPG in CI. I suppose it makes some amount of sense to update the token if someone tries to run MPG commands in CI; but it will never have worked in the first place, so we wouldn’t be breaking any new jobs.

[jphenow]

Later today a new version will be released that makes it apparent that you should upgrade your tokens when people run into this:

detect if we're using compatible tokens for MPG commands

Thanks for the bump on this @moishinetzer

[moishinetzer]

Holy shmoley that was fast. Bet this bumps the average SLA!

Thanks for speedy fix on this. I’m over the hurdle but glad this will help others!