How is the "config is unchanged" decision made?

I would like to confirm one thing as I debug my code. This code basically takes information from docker and pushes reverse proxy routes to caddy via the API. A replacement for Traefik of sorts :slightly_smiling_face:

I see that some routes I want to push (via /load) are different from the respective current ones in caddy (which I get via /config). This is OK - the route which is pushed is the correct one.
Specifically, the IP address in one of the handles is different in both cases:

        "handle": [
                      "handler": "reverse_proxy",
                      "upstreams": [
                          "dial": ""  ← this is different between /load and /config

Despite this difference, caddy logs

{"level":"info","ts":1589383873.8353689,"logger":"admin.api","msg":"config is unchanged"}

which obviously is troubling. (not only it logs but the config indeed stays unchanged)

My question: how is the change computed? Or more specifically: should a change in a dial field trigger a reload of caddy?

How can we reproduce the behavior you’re seeing?

The code that does the check whether the config is changed is here:

It simply compares whether the configs are byte-equal. Seems to me like whatever you’re doing didn’t actually make the change you expected!

Thanks a lot! That clarifies the issue, the IP change was 1 or 2 off so the string had the same length.

I will keep track of the changes on my end then, but I think the check is nevertheless too weak (it should be a real diff of the maps (of this is what a dictionary is called in Go))


Equal reports whether a and b are the same length and contain the same bytes. A nil argument is equivalent to an empty slice.

It’s not just length, it’s byte equality as well. It’s taking the JSON as raw bytes, and comparing those. Only exact matches would trigger that error. The code in Caddy is correct.

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