⬆️ Upgrade axios to 1.18.1 + fix rail API proxy fallback#638
Conversation
Bump axios from 1.4.0 to 1.18.1 in the app. Verified no behavioral regressions in our usage (relative URLs + baseURL, single response interceptor, manual query strings); the range is mostly security hardening. Claude-Session: https://claude.ai/code/session_019pKVy8kopwm4fqoL6LEzfk
The 403 fallback only changed axiosInstance.defaults.baseURL, but replayed error.config — which carries an explicit baseURL that takes precedence over defaults. The retry therefore hit the direct API again and failed. Override baseURL on the replayed request itself so it actually reaches the proxy. Claude-Session: https://claude.ai/code/session_019pKVy8kopwm4fqoL6LEzfk
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request upgrades axios from 1.4.0 to 1.18.1 and updates the fallback mechanism in rail-api.ts to explicitly override the baseURL on the replayed request. Feedback points out that the config object from the error interceptor could be undefined, which would cause issues when spreading it. It is recommended to add a guard check to ensure config is defined before attempting the retry.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| // Override baseURL on the replayed request itself — an explicit | ||
| // config.baseURL takes precedence over defaults.baseURL, so changing | ||
| // the default alone would send the retry back to the direct API. | ||
| const originalRequest = { ...config, baseURL: API_CONFIG.PROXY_RAIL_API } |
There was a problem hiding this comment.
The config object from an AxiosError can be undefined. If it is, spreading it here will result in an incomplete request configuration, likely causing the retried request to fail unexpectedly or behave incorrectly.
To prevent this, you should add a guard to ensure config is defined before attempting to retry the request.
A good place for this check would be in the if condition on line 37:
if (response?.status === 403 && !this.hasFallenBackToProxy && config) {This ensures that the fallback logic is only triggered when a request can actually be replayed.
1 participant
Summary
axiosin the app from 1.4.0 → 1.18.1 (latest).axios upgrade
Verified against both 1.4.0 and 1.18.1 that our usage has no behavioral regressions: we use relative URLs with
baseURL, a single response interceptor, and build query strings manually (noparams/paramsSerializer). The 1.4 → 1.18 range is overwhelmingly security hardening (CSRF, prototype pollution, CRLF header injection, SSRF/redirect fixes).Proxy fallback fix
RailApi's response interceptor falls back to the proxy endpoint on a 403, but it only reassignedaxiosInstance.defaults.baseURLand then replayederror.config. Since an explicitconfig.baseURLtakes precedence overdefaults.baseURLin axios, the replayed request kept the original directbaseURLand hit the direct API again — so the fallback never actually reached the proxy. This behaved identically on 1.4.0, so it's a long-standing bug, not a regression.The fix overrides
baseURLon the replayed request itself.Verification
Reproduced the interceptor logic against the real installed axios (1.18.1) with a mock adapter that 403s on the direct host and 200s on the proxy:
https://claude.ai/code/session_019pKVy8kopwm4fqoL6LEzfk