e2e: backup access preflight discards the port-forward log on the failure path that needs it #4240

Describe the bug

hack/e2e-chainsaw/_lib/backup-access-preflight.sh captures the port-forward it depends on, but prints that capture only when the port-forward never comes up. On the path that actually fails in practice, S3 operations failing after a healthy port-forward, the log is written and then discarded.

The same step also truncates its mc log at the top of every attempt, so the output shows the last attempt and nothing about the ones before it.

Environment

• Cozystack: main
• In-tree e2e lane

To Reproduce

Have the preflight fail its PUT/GET/DELETE loop, for example run 34864316378, suite clickhouse-2-backup-roundtrip.

Expected behaviour

A failure prints what is needed to tell apart "the channel to S3 broke" from "S3 refused the operation".

Actual behaviour

The setup path prints the port-forward log:

if ! timeout 30 sh -ec "until nc -z 127.0.0.1 ${local_port}; do sleep 1; done"; then
  echo "S3 preflight port-forward did not become ready" >&2
  sed 's/^/  port-forward: /' "${workdir}/port-forward.log" >&2
  return 1
fi

The failure path does not:

if [ "$(date +%s)" -ge "${deadline}" ]; then
  echo "BucketAccess ... was granted but did not pass S3 PUT/GET/DELETE within ${timeout_seconds}s" >&2
  sed 's/^/  s3-preflight: /' "${workdir}/mc.log" >&2
  return 1
fi

And each attempt starts with : > "${workdir}/mc.log", so whatever earlier attempts reported is gone by the time anything is printed.

What that produced in the run above: exactly one line of evidence, the progress line of an upload that did not complete.

s3-preflight: `/tmp/tmp.1QUkBGPjwP/source` -> `backup-preflight/bucket-6af22edd-.../...`

Additional context

This is a diagnosability bug rather than a correctness one, and it has a cost worth recording: reading that single line, I first concluded the upload had succeeded and the download hung, and went looking at the wrong half of the system. The S3 gateway's own logs showed the opposite — the PUT was what failed, putToFiler could not get a volume assigned. The real cause is filed as #4239.

Two changes would have made the run self-explaining: print port-forward.log alongside mc.log on the timeout path, and append to mc.log across attempts rather than truncating, or at least record how many attempts ran and how each ended.

Checklist

• I have checked the documentation
• I have searched for similar issues
• I have included all required information
• I have provided clear steps to reproduce
• I have included relevant logs