[burnedikt]

retrieve_client_application_version() was the only request in ClientApplicationApiClient that sent no Authorization header. main() uses it as the pre-flight duplicate check before an upload:

check_response = client_applications_api.retrieve_client_application_version(args.slug, args.version)
if check_response.status_code < 400:
    print(f"Version {args.version} already existing! Aborting.")
    exit(1)

Portal only serves the current version of a client application to anonymous callers, so for any version that has since been superseded the unauthenticated lookup gets a 404 and the check concludes "doesn't exist". The binary is then chunk-uploaded and the run fails on the backend's uniqueness constraint with a bare 400 — instead of aborting cleanly before doing any work.

Normal releases are unaffected either way (a genuinely new version 404s before and after). This only shows up when re-uploading a version that already exists and is no longer current — e.g. re-running a release job.

Sending the credentials the rest of the client already uses restores the clean abort. Added tests/test_client_application_uploader.py to pin that the lookup carries the header.

Context: this surfaced while auditing consumers of the client-application endpoints for Innoactive/Portal-Backend#2280, which tightens anonymous read access to superseded versions.

The branch also carries a one-line uv.lock fix: the 3.5.0 release commit bumped pyproject.toml only, so CI's uv sync --locked rejected the lockfile, which still recorded portal-client 3.4.1.

uv sync --locked passes; uv run pytest → 51 passed. ruff format --check is clean on both touched files. ruff check reports only the pre-existing exit() → sys.exit() findings (PLR1722) in main(), on lines this PR leaves untouched.

🤖 Generated with Claude Code

[innoactive-semantic-release]

🎉 This PR is included in version 3.6.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀