Server port and admin server port can end up with the same value about postgrest HOT 6 OPEN

One of them is listening on ipv4, the other on ipv6.

Generally, a user expects us to stick to one protocol, right? Meanwhile, one way to reduce confusion would be reporting URLs of apps to reach them at instead of just port numbers (and we do have all the info required for it).

from postgrest.

The problem here is the app server binds to [::1]:3000 and admin server binds to 127.0.0.1:3000 because bindPortTCP binds to whatever address available and localhost resolves in both [::1] and 127.0.0.1 addresses.

Anyway, with #3512 admin server is bound to the same address as main, so specifying the same port results in a runtime error:

❯  PGRST_SERVER_PORT=3000 PGRST_SERVER_HOST='localhost' PGRST_ADMIN_SERVER_PORT=3000 postgrest-with-postgresql-16 postgrest-run
postgrest-with-postgresql-16: You can connect with: psql 'postgres:///postgres?host=/run/user/1000/postgrest/postgrest-with-postgresql-16-BBy/socket' -U postgres
postgrest-with-postgresql-16: You can tail the logs with: tail -f /run/user/1000/postgrest/postgrest-with-postgresql-16-BBy/db.log
postgrest: Network.Socket.bind: resource busy (Address already in use)
Temporary directory kept at: /run/user/1000/postgrest/postgrest-with-postgresql-16-BBy

Although the above runtime error is rather uninformative. I wonder if I should validate the config and fail if port numbers match, or just add logs, like binding main app to <hostname>:<port>; binding admin app to <hostname>:<port>? The latter could be useful to admins either way, and the runtime error would make perfect sense either way: when ports are equal — the problem is with the PostgREST config; otherwise there's some other service occupying the same port.

from postgrest.

Okay, we actually do diagnostic messages "[Admin server] listening on port <port>", but in the case of the port conflict neither of those is shown before the runtime error.

from postgrest.

Generally, a user expects us to stick to one protocol, right?

This sounds very plausible - but I'm not 100% sure.

I can easily imagine scenarios where I don't want this to be the case.

Isn't the whole problem here that we only have server-host, but not admin-server-host?

I think it's quite reasonable to have the admin server listen on 127.0.0.1 only, but the regular server on 0.0.0.0.

So even if it's the same protocol, we probably still need a way to allow setting different hosts.

Meanwhile, one way to reduce confusion would be reporting URLs of apps to reach them at instead of just port numbers (and we do have all the info required for it).

Agreed, that would be really good.

Overall, even given both admin-server-host and the display of URLs, I think we should still prevent using the same port number on both on the config level already. This only leads to confusion and ambiguity.

from postgrest.