chore: try to refresh login on long dev servers

[Nsttt]

What's added in this PR?

• Adds auth refresh context (application_uid, git_config) into asset and snapshot uploads so long-running dev servers can refresh credentials.
• Adds retry-on-auth-expiry behavior for uploadFile and uploadSnapshot using refreshed application config/JWT.
• Preserves forbidden authorization failures (ERR_AUTH_FORBIDDEN_ERROR) instead of converting them into ERR_JWT_INVALID.
• Centralizes auth refresh helpers in auth/refresh-auth.ts for consistent retryable/forbidden auth semantics.
• Prevents repeated auth refreshes across asset batches by refreshing once per batch/env in zeUploadAssets and reusing refreshed config.
• Adds a new unit test for zeUploadAssets to verify single refresh and config reuse across multi-asset uploads.

Screenshots

• N/A (backend/agent behavior change)

What's the issues or discussion related to this PR ?

• ClickUp: https://app.clickup.com/t/9013031642/ZE-1132
• ZE-1132: long-running sessions can end up with stale JWTs during upload operations. This PR refreshes auth/config when needed, retries only for unauthenticated errors, keeps forbidden errors explicit, and avoids repeated refresh churn during batch uploads.

What are the steps to test this PR?

1. Run focused unit tests:
   • pnpm nx test zephyr-agent --testPathPattern=upload-file.test.ts
   • pnpm nx test zephyr-agent --testPathPattern=upload-snapshot.test.ts
   • pnpm nx test zephyr-agent --testPathPattern=ze-upload-assets.test.ts
2. Validate hook/build path:
   • pnpm nx build with-zephyr
3. Verify behavior manually (optional):
   • simulate expired auth and confirm upload retries once with refreshed JWT
   • simulate forbidden auth and confirm it fails with forbidden error
   • for multi-asset upload with expired JWT, confirm refresh occurs once and all uploads reuse refreshed config

Documentation update for this PR (if applicable)?

• Not required (no user-facing API/config changes).

(Optional) What's left to be done for this PR?

• Optional: add a higher-level integration/e2e scenario covering token expiry during full deploy flow.

(Optional) What's the potential risk and how to mitigate it?

• Risk: auth error categorization drift over time.
• Mitigation: centralized helper + unit tests for retryable vs forbidden paths and batch refresh behavior.

(Required) Pre-PR/Merge checklist

• I have added/updated/opened a PR to documentation to cover this new behavior
• I have added an explanation of my changes
• I have written new tests (if applicable)
• I have tested this locally (standing from a first time user point of view, never touch this app before)
• I have/will run tests, or ask for help to add test

[nx-cloud]

🤖 Nx Cloud AI Fix Eligible

An automatically generated fix could have helped fix failing tasks for this run, but Self-healing CI is disabled for this workspace. Visit workspace settings to enable it and get automatic fixes in future runs.

_{To disable these notifications, a workspace admin can disable them in workspace settings.}

---

View your CI Pipeline Execution ↗ for commit 3a4f72d

Command	Status	Duration	Result
nx run e2e-deployment:e2e-test -- --passWithNoT...	❌ Failed	47s	View ↗
nx affected -t build --skipRemoteCache	✅ Succeeded	2m 38s	View ↗
nx affected -t test	✅ Succeeded	2m 9s	View ↗
nx affected --exclude=!libs/** -t build --skipR...	✅ Succeeded	26s	View ↗
nx affected -t lint	✅ Succeeded	7s	View ↗

---

☁️ Nx Cloud last updated this comment at 2026-02-19 11:46:08 UTC