[Bug] Docker-compose seems to fail "error: Uncaught (in promise) URIError: invalid port number"

[petercockroach]

Docker-compose seems to fail "error: Uncaught (in promise) URIError: invalid port number"

docker-compose.yml

moviematch:
image: lukechannings/moviematch
hostname: moviematch
container_name: moviematch
environment:
- PLEX_URL=http://:32400
- PLEX_TOKEN=""
ports:
- xxxx:8000

Expected behavior
It seems no matter what ports I set, I get an error and the container fails to come up:

INFO Listening on port 8000
error: Uncaught (in promise) URIError: invalid port number
at processResponse (deno:core/core.js:223:11)
at Object.jsonOpAsync (deno:core/core.js:240:12)
at async fetch (deno:op_crates/fetch/26_fetch.js:1278:29)
at async getSections (plex.ts:30:15)
at async plex.ts:74:20

Desktop (please complete the following information):

• OS: Docker on macOS 11.1

[LukeChannings]

Your PLEX_URL is malformed

[petercockroach]

Copy-paste fail. It's correctly configured as:

• PLEX_URL=http://192.168.x.y:32400

[petercockroach]

Why was this closed? It’s still a problem.

[LukeChannings]

Sorry, I misunderstood your last message.

That URI looks ok to me...

Can you please:

• use the lukechannings/moviematch:develop image
• Set LOG_LEVEL=DEBUG
• Post the logs (make sure x-plex-token is redacted)

[petercockroach]

DEBUG Log level DEBUG
DEBUG getSections: http://192.168.x.y:32400 /library/sections
INFO Listening on port 8000
error: Uncaught (in promise) URIError: invalid port number
at processResponse (deno:core/core.js:223:11)
at Object.jsonOpAsync (deno:core/core.js:240:12)
at async fetch (deno:op_crates/fetch/26_fetch.js:1278:29)
at async getSections (plex.ts:32:15)
at async plex.ts:76:20

[LukeChannings]

@petercockroach

It looks like you have trailing whitespace in your env variable. Using a .env file automatically trims whitespace, but not when using environment variables.

I've pushed a fix to :develop, can you confirm it's working?

[petercockroach]

ok...so here's what I found:

1. My plex token was in quotes that needed to be removed so PLEX_TOKEN="my_token" became PLEX_TOKEN=my_token.
2. Most of my other services have environment variables written like this:
   environment:
   • ARGS="" \
   • TZ=America/Los_Angeles \
   • DEBUG="no" \

If I add a space and trailing slash, it fails. I can confirm that adding just a trailing space still works, but the trailing slash fails.

[LukeChannings]

Did you arrive at a working docker-compose file?

Can you post it?

[petercockroach]

docker-compose.txt

[LukeChannings]

Ok,

I've had a look into it and have found:

• The compose file (v3) spec does not instruct users to quote the value when using a YAML list. Quoting is fine if you're using a YAML map, however.
• Using a .env file supports quoting (PLEX_URL="https://plex.example.com"), because the env file is based on a POSIX shell DSL, and not a YAML string formatted like KEY=VALUE
• There is an issue against docker/compose that details the problem here

Conclusion:

• Don't quote values if you're using a docker-compose string list
• Feel free to quote values in all other cases

I'm not going to update MovieMatch to trim quotes, because it's additional maintenance that I'm not willing to take on. This is a configuration issue, arguably docker-compose should fix it, but either way it's not something that should be fixed in this codebase.

I will update the docs to include an example docker-compose.yaml to hopefully help future users.

I have released 1.6.0 with the whitespace trimming to that MovieMatch's env file and environment variable handling is consistent wrt whitespace.

Thanks for taking the time to report this and responding with more info, I hope you like MovieMatch!

[petercockroach]

Thanks Luke. What about issue 2 with the trailing slash? Is that incorrect as well?

[LukeChannings]

There are a lot of different pieces that need to be explained, so forgive me if I'm not totally clear.

When a program runs it has environment variables available to it. You set these variables in different ways depending on your Operating System, your shell, etc.

In BASH, for example, you can set environment variables by prefixing KEY=VALUE before a given command:

FOO=bar env | grep FOO

Sometimes you need to specify a lot of environment variables, which results in a long line, like:

FOO=bar SOMETHING=GgIpjc6LRuG4Q1axtWYGeT5ooPs4zB7NcO3ky4aO ELSE=uQmzxbnPFZ3PREU1FBzf8SE5V6ckFiqNPyZmi3dj my-command

That's not very readable, so it's common to use a multi-line command by escaping the \n (new line) character, which looks like this:

FOO=bar \
SOMETHING=GgIpjc6LRuG4Q1axtWYGeT5ooPs4zB7NcO3ky4aO \
ELSE=uQmzxbnPFZ3PREU1FBzf8SE5V6ckFiqNPyZmi3dj \
my-command

Seem familiar?

This is a shell script syntax, and escaping the newline is valid, as well as quoting the values, e.g. FOO="bar" (in fact quoting values is recommended in BASH to avoid accidental glob expansions).

But... that's not anything to do with a docker-compose file, which is a YAML document, and has its own syntax. For example, in YAML, values that aren't obviously a number are automatically strings, so in this example:

map:
  key: value
list:
  - key=value

that translates to:

{
  "map": { "key": "value" },
  "list: ["key=value"]
}

So, if you quoted the value in the list example (- key="value"), that'd actually become ["key=\"value\"]. See the problem?

There is an additional complication of services / programs that rely on YAML that has a shell script embedded within it, like GitHub Actions:

jobs:
  build:
    steps:
      - run |
        FOO=bar \
        SOMETHING=GgIpjc6LRuG4Q1axtWYGeT5ooPs4zB7NcO3ky4aO \
        ELSE=uQmzxbnPFZ3PREU1FBzf8SE5V6ckFiqNPyZmi3dj \
        my-command

It can be difficult to know what's what, but reading the documentation is your best bet. The docker compose file is well documented here, and I'd recommend having a read through it. Especially the section on environment.

I hope this helps.