Confusing warning: app is not listening on the expected address and will not be reachable by fly-proxy

Questions / Help
1

I am sure I am doing something wrong here, but also, something could be improved at least in flyctl.

When I deploy my app I get this warning:

WARNING The app is not listening on the expected address and will not be reachable by fly-proxy.
You can fix this by configuring your app to listen on the following addresses:
  - 0.0.0.0:0ing for job
Found these processes inside the machine with open listening sockets:
  PROCESS                   | ADDRESSES                              
----------------------------*----------------------------------------
  /.fly/hallpass            | [fdaa:0:6218:a7b:cf99:1175:fd04:2]:22  
  /app/bin/lap-open-wire-db | [::]:8080

Note that the IP and Port are overlapping with some other text, which makes it really hard to tell what’s actually going on here. On top of that I don’t actually know why I should care about the port not being reachable by fly-proxy; even with this happening, my apps health checks are passing and I can access it over the internet (see for yourself.)

Should I just ignore this?

In case it’s relevant, here’s my fly.toml:

# fly.toml app configuration file generated for lap-open-wire-search on 2024-04-01T10:30:40-07:00
#
# See https://fly.io/docs/reference/configuration/ for information about how to use this file.
#

app = 'lap-open-wire-search'
primary_region = 'dfw'
kill_signal = 'SIGINT'
kill_timeout = '5s'

[env]
  PORT = '8080'

[[services]]
  protocol = 'tcp'
  internal_port = 8080
  processes = ['app']

[[services.ports]]
    port = 80
    handlers = ['http']
    force_https = true

[[services.ports]]
    port = 443
    handlers = ['tls', 'http']

  [services.concurrency]
    type = 'connections'
    hard_limit = 25
    soft_limit = 20

[[http_service.checks]]
  grace_period = "10s"
  interval = "30s"
  method = "GET"
  timeout = "5s"
  path = "/"

[[vm]]
  memory = '1gb'
  cpu_kind = 'shared'
  cpus = 1
2

I’m running into this as well. Unfortunately, I think there’s an ongoing incident causing some issues.

3

This may be the cause of that:

Looks like it is being resolved right now.

4

I sure hope that’s the case. My app health checks failed after a new deploy 20+ minutes ago and I’ve not been able to get it back up since then.

5

FYI the status is returned to normal but I am still seeing the same behavior. I think that I’m seeing a slight bug in flyctl (the rendering error) and experiencing a suboptimal configuration due to some mistake I made.

6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.