LiteFS "Unsolicited response received on idle HTTP channel" log message


I’ve followed this documentation on getting started with LiteFS on Fly, and some of the time when the application serves a request I get this message logged:

2023-09-23T17:29:52Z app[3d8d313c223438] lhr [info]level=INFO msg="Unsolicited response received on idle HTTP channel starting with \"<!DOCTYPE html>\\n<html>\\n<head>\\n<meta charset=\\\"utf-8\\\" />\\n<meta http-equiv=\\\"content-type\\\" content=\\\"text/html;...

From my testing there seems to be no difference to the client whether or not this is logged.

I’ve not managed to determine any pattern as to when this does or does not happen. What might be happening here?


Hmm, that’s a new error. I haven’t seen that before. Can you share your fly.toml & litefs.yml?

Sure thing. I believe it’s the defaults.

# See for information about how to use this file.

app = "gleam-packages"
primary_region = "lhr"
kill_signal = "SIGINT"
kill_timeout = "5s"

  auto_rollback = true

  DATABASE_PATH = "/litefs/packages.sqlite"

  protocol = "tcp"
  internal_port = 3001
  processes = ["app"]

    port = 80
    handlers = ["http"]
    force_https = true

    port = 443
    handlers = ["tls", "http"]
    type = "connections"
    hard_limit = 25
    soft_limit = 20

    interval = "15s"
    timeout = "2s"
    grace_period = "1s"
    restart_limit = 0

  source = "packages_litefs"
  destination = "/var/lib/litefs"
# The fuse section describes settings for the FUSE file system. This file system
# is used as a thin layer between the SQLite client in your application and the
# storage on disk. It intercepts disk writes to determine transaction boundaries
# so that those transactions can be saved and shipped to replicas.
  dir: "/litefs"

# The data section describes settings for the internal LiteFS storage. We'll 
# mount a volume to the data directory so it can be persisted across restarts.
# However, this data should not be accessed directly by the user application.
  dir: "/var/lib/litefs"

# This flag ensure that LiteFS continues to run if there is an issue on starup.
# It makes it easy to ssh in and debug any issues you might be having rather
# than continually restarting on initialization failure.
exit-on-error: false

# This section defines settings for the option HTTP proxy.
# This proxy can handle primary forwarding & replica consistency
# for applications that use a single SQLite database.
  addr: ":3001"
  target: "localhost:3000"
  db: "packages.sqlite"
    - "*.css"
    - "*.js"

# This section defines a list of commands to run after LiteFS has connected
# and sync'd with the cluster. You can run multiple commands but LiteFS expects
# the last command to be long-running (e.g. an application server). When the
# last command exits, LiteFS is shut down.
  - cmd: "/app/ run server"

# The lease section specifies how the cluster will be managed. We're using the
# "consul" lease type so that our application can dynamically change the primary.
# These environment variables will be available in your application.
  type: "consul"
  advertise-url: "http://${HOSTNAME}.vm.${FLY_APP_NAME}.internal:20202"
  candidate: ${FLY_REGION == PRIMARY_REGION}
  promote: true

    url: "${FLY_CONSUL_URL}"
    key: "litefs/${FLY_APP_NAME}"

I would be happy for you to use my application for debugging if that helps.

Your config looks good. Yeah, that’d be great if I could poke around at the app to see what’s going on. Is it open source? If not, you can email me privately at

1 Like

It’s open source: GitHub - gleam-lang/packages: 📦 Search for Gleam packages

I’m also happy for you to inspect my Fly app, including the logs. It’s all public as far as I’m concerned, and can tolerate a little downtime too.

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