fastly
setBackendsWithDefaultOverrideHostIfMissing doesn't actually do anything
Version
% fastly version
Fastly CLI version v10.19.0 (33a28544)
Built with go version go1.22.12 linux/amd64 (2025-03-09)
Viceroy version: viceroy 0.12.2
What happened
In #843, a feature was added that checks if override_host is defined for each backend defined in local_server, and sets one equal to the hostname specified as the url.
Unfortunately, after this value is set in memory, it is not actually passed into Viceroy (Viceroy only receives the path to fastly.toml), so it does not see the updated value.
The expected behavior is for the override_host value that is set by this feature to reflect in the Viceroy session that is spawned.
I think this can be a source of confusion as it logs a message saying it is going to assign override_host, but the change actually never makes it to Viceroy.
INFO: [local_server.backends.http-me] (https://http-me.glitch.me) is configured without an `override_host`. We will use http-me.glitch.me as a
default to help avoid any unexpected errors. See
https://www.fastly.com/documentation/reference/compute/fastly-toml#local-server for more details.
After a quick read of the code, I agree... I don't see how the 'temporary' backend modifications are supposed to be used by Viceroy, as the manifest file isn't written back out (that would overwrite the user's manifest file) and there is no temporary manifest file written either.
@Integralist I know this is becoming ancient history for you at this point, but can you remember what #843 was expected to actually do?
this is becoming ancient history for you
<Checks PR>: code written over two years ago 😅
From what I can tell from the PR description and the code, it looks like it was trying to set the override_host setting for any backend that doesn't have one defined, for the reason that if a backend doesn't have that set, it can often be a mistake. I think this might have been something Andrew Betts asked me about implementing due to issues that had been noticed out in the world.
I recall there being a few places in the CLI where the manifest would be persisted back to disk and so maybe (at the time) there was a call somewhere else in the app run function that was doing that as a side effect and so there was no reason to explicitly call the same write function from within the server exec function.
I'm just spit-balling at this point as this is long lost context for me I'm afraid.
Fair enough, I suspected that might be the case. Given that, I think our only solution for this is going to be persisting the modified manifest to a temporary file, telling Viceroy to use that, and then cleaning it up after Viceroy shuts down. Not ideal, but without a way to directly pass manifest content to Viceroy (bypassing the filesystem), I can't think of a better option.