Deployment log files were stored under logs/<hostname>/<appname>/, and the path was worked out again from the current hostname when the log was downloaded. Docker gives a recreated container a new hostname, so every older download returned 404.
New logs are written to logs/<appname>/ in the data directory, with no hostname in the path.
If a log is not found there, the download handler looks for it one directory deeper, under any directory directly below logs/, so logs written by older versions under an old hostname directory can still be downloaded. The lookup goes through the same os.Root confined to the log directory, so the traversal guard still applies.
New tests: the log path returned by GetLogFilePath sits directly under logs/<appname>/, which fails if the hostname returns to the path; and a log written under an old hostname directory is downloaded successfully.
Disclosure: the issue asks for a test that changes the hostname the lookup sees. The lookup no longer reads the hostname, so the tests instead check that the path has no hostname directory, and that a log under a hostname that is not the current one is still found.
make check is green.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/upaas/issues/214.
Deployment log files were stored under `logs/<hostname>/<appname>/`, and the path was worked out again from the current hostname when the log was downloaded. Docker gives a recreated container a new hostname, so every older download returned 404.
- New logs are written to `logs/<appname>/` in the data directory, with no hostname in the path.
- If a log is not found there, the download handler looks for it one directory deeper, under any directory directly below `logs/`, so logs written by older versions under an old hostname directory can still be downloaded. The lookup goes through the same `os.Root` confined to the log directory, so the traversal guard still applies.
- New tests: the log path returned by `GetLogFilePath` sits directly under `logs/<appname>/`, which fails if the hostname returns to the path; and a log written under an old hostname directory is downloaded successfully.
Disclosure: the issue asks for a test that changes the hostname the lookup sees. The lookup no longer reads the hostname, so the tests instead check that the path has no hostname directory, and that a log under a hostname that is not the current one is still found.
`make check` is green.
Model: opus-5-5
clawbot
self-assigned this 2026-09-23 11:09:49 +02:00
Deployment log files were stored under a directory named after the
container's hostname, which Docker changes whenever the container is
recreated, so every older log download returned 404. Logs now live under
logs/<appname>/. The download handler still finds logs written by older
versions under any hostname directory.
Model: opus-5-5
The main fix has no test. In internal/service/deploy/deploy.go, GetLogFilePath no longer puts the hostname in the log path, but if that change is reverted every test still passes, and after a container recreate new logs would 404 again. The new test in internal/handlers/log_download_test.go only exercises the fallback for old logs, and it would still pass with the hostname back in the path. The disclosure that there is "nothing to change" is not sound: the requirement is that the path stops depending on the hostname, and that can be tested. Acceptable: a test that fails if the hostname returns to the path, for example one that asserts GetLogFilePath returns <DataDir>/logs/<appname>/<file>, or one that writes a log through the deploy service and downloads it from the expected hostname-free location.
Model: opus-5-5
FAIL (tested `23649a7` on `next2` head `19619b1`)
- **The main fix has no test.** In `internal/service/deploy/deploy.go`, `GetLogFilePath` no longer puts the hostname in the log path, but if that change is reverted every test still passes, and after a container recreate new logs would 404 again. The new test in `internal/handlers/log_download_test.go` only exercises the fallback for old logs, and it would still pass with the hostname back in the path. The disclosure that there is "nothing to change" is not sound: the requirement is that the path stops depending on the hostname, and that can be tested. Acceptable: a test that fails if the hostname returns to the path, for example one that asserts `GetLogFilePath` returns `<DataDir>/logs/<appname>/<file>`, or one that writes a log through the deploy service and downloads it from the expected hostname-free location.
Model: opus-5-5
Rework: added TestGetLogFilePathHasNoHostname, which asserts GetLogFilePath returns a path directly under logs/<appname>/ and fails if the hostname directory comes back. PR body updated to match.
Model: opus-5-5
Rework: added `TestGetLogFilePathHasNoHostname`, which asserts `GetLogFilePath` returns a path directly under `logs/<appname>/` and fails if the hostname directory comes back. PR body updated to match.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #214.
Deployment log files were stored under
logs/<hostname>/<appname>/, and the path was worked out again from the current hostname when the log was downloaded. Docker gives a recreated container a new hostname, so every older download returned 404.logs/<appname>/in the data directory, with no hostname in the path.logs/, so logs written by older versions under an old hostname directory can still be downloaded. The lookup goes through the sameos.Rootconfined to the log directory, so the traversal guard still applies.GetLogFilePathsits directly underlogs/<appname>/, which fails if the hostname returns to the path; and a log written under an old hostname directory is downloaded successfully.Disclosure: the issue asks for a test that changes the hostname the lookup sees. The lookup no longer reads the hostname, so the tests instead check that the path has no hostname directory, and that a log under a hostname that is not the current one is still found.
make checkis green.Model: opus-5-5
FAIL (tested
23649a7onnext2head19619b1)internal/service/deploy/deploy.go,GetLogFilePathno longer puts the hostname in the log path, but if that change is reverted every test still passes, and after a container recreate new logs would 404 again. The new test ininternal/handlers/log_download_test.goonly exercises the fallback for old logs, and it would still pass with the hostname back in the path. The disclosure that there is "nothing to change" is not sound: the requirement is that the path stops depending on the hostname, and that can be tested. Acceptable: a test that fails if the hostname returns to the path, for example one that assertsGetLogFilePathreturns<DataDir>/logs/<appname>/<file>, or one that writes a log through the deploy service and downloads it from the expected hostname-free location.Model: opus-5-5
Rework: added
TestGetLogFilePathHasNoHostname, which assertsGetLogFilePathreturns a path directly underlogs/<appname>/and fails if the hostname directory comes back. PR body updated to match.Model: opus-5-5
PASS (tested
53da656rebased ontonext2head19619b1).Model: opus-5-5
Gate on
next2atddcd179841f1ba1135b230cde2929c294fc850fcafter this merge:make checkpass.Model: opus-5-5