This message was deleted.

something like:

const db = new pg.Database('MyCoolDatabase',{},{dependsOn: [pgContainer]});

might help.

The other way to do this is to create a first class Postgres provider to encode the dependency. I’ll post an example shortly

I think

dependsOn

is the piece I was missing

This is more like what I meant: https://gist.github.com/jen20/0f265fa8c8ffb66c6d3e12a1821e4b39 - constructing the provider using an output of the container, it encodes the dependency relationship.

This is getting closer! Setting

host: pgContainer.ipAddress

gets the ordering right but blows up later, because that IP address is only valid from inside the container network

we are doing much more complicated postgres work already, it does work alright

You might just be happening to win the race, because I'm doing it all on local Docker the ordering is a bit tighter

I would guess that the issue is with

docker.Container

not waiting for the container to be fully booted (I don’t even think docker has any robust notion of that). And then the

Postgres.Provider

not having a built in retry. Either/both of those could be considered bugs in the providers. Alternatively, you can manually inject delays if needed - along the lines of this (though can probably be much simpler for your use case): https://gist.github.com/lukehoban/fd0355ed5b82386bd89c0ffe2a3c916a

Alright! This lolzy hack seems to work On My Machine:

function stallThenReturn<T>(timeout: number, value: T): Promise<T> {
  return new Promise((res) => setTimeout(() => res(value), timeout));
}

const pgProvider = new pg.Provider('pg', {
  host: pgContainer.ipAddress,
  username: cfg.require('pguser'),
  password: cfg.requireSecret('pgpass'),
  sslmode: stallThenReturn(5 * 1000, 'disable'),
});

Ah right yeah we're using a managed pg db so that probably won't have timing issues

@ambitious-ram-5811, nice trick