-
Notifications
You must be signed in to change notification settings - Fork 0
[Feat] axios 인터셉터 refresh 로직 추가 #217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from 1 commit
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_retry플래그 설정이 누락되어 무한 루프가 발생할 수 있습니다.originalRequest._retry를 확인하지만, 재시도 전에true로 설정하지 않습니다. 재시도된 요청이 다시 401을 반환하면 또 다른 refresh 시도가 발생하여 무한 루프에 빠질 수 있습니다.🔎 수정 제안
if (status === 401 && !originalRequest._retry) { + originalRequest._retry = true; try { await API.authService.refresh(); return baseAPI(originalRequest); } catch (refreshError) {🤖 Prompt for AI Agents
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
이미 API.authService.refresh 함수에서 _retry: true로 강제 설정하고 있기 때문에 무한 루프가 발생하지 않습니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🏁 Script executed:
Length of output: 1053
@Chiman2937, 말씀하신 내용을 확인했습니다. 다만 약간의 혼동이 있는 것 같습니다:
현재 구현:
API.authService.refresh()에서{ _retry: true }를 설정하는 것은 refresh 요청 자체 (POST /auth/refresh)에 대한 플래그입니다하지만:
originalRequest(처음 401을 받은 요청)에는_retry플래그가 여전히 설정되지 않습니다return baseAPI(originalRequest)재시도!originalRequest._retry조건이 여전히 true (undefined)권장 사항:
이렇게 하면 모든 엣지 케이스를 안전하게 방지할 수 있습니다. 현재 로직이 대부분의 경우 동작하더라도,
originalRequest._retry를 명시적으로 설정하는 것이 더 안전한 방법입니다.🧬 Code Graph Analysis Results
[src/api/core/index.ts] 401 handling block (shows use of originalRequest._retry and refresh flow)
if (status === 401 && !originalRequest._retry) {
try {
await API.authService.refresh();
return baseAPI(originalRequest);
} catch (refreshError) {
if (isServer) {
const { redirect } = await import('next/navigation');
redirect('/login');
} else {
if (window.location.pathname === '/login') {
throw errorResponse;
}
const currentPath = window.location.pathname + window.location.search;
window.location.href =
/login?error=unauthorized&path=${encodeURIComponent(currentPath)};}
throw refreshError;
}
}
[src/api/index.ts] provide API service reference (relevant to understanding how API.authService.refresh is accessed)
export const API = provideAPIService();
[src/types/service/common.ts] Common error/success response types (context for error handling in interceptors)
export interface CommonErrorResponse {
type: string;
title: string;
status: number;
detail: string;
instance: string;
errorCode?: string;
}
export interface CommonSuccessResponse {
status: number;
success: boolean;
data: T;
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
해당 내용은 논리적으로 이해 되지 않습니다.
GET /api/v1/users/me와POST /api/v1/groups/createapi가 동시에 호출된다고 가정하겠습니다.이때 originalRequest._retry를 true로 설정한다고 해도 각 api 호출 시 axios 인스턴스가 별도로 생성되기 때문에 _retry 플래그를 true로 설정한다고 해서 서로 공유되지 않습니다. 이 때문에 _retry 플래그를 true를 설정하는 것이 의미가 없다고 생각됩니다.
애초에 status 401이 발생했을 때는 refresh 호출 로직밖에 없고, 그 후에는 다시 원래 api를 호출하는 것이 아닌 /login 페이지로 리다이렉트 되면서 api 호출을 중단합니다.
여기서 무한루프를 일으킬 여지가 있나요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Chiman2937, 좋은 질문입니다. 제가 설명을 더 명확히 드리겠습니다.
1번 포인트에 대한 답변:
_retry플래그의 위치_retry플래그는 axios 인스턴스가 아닌 요청 config 객체(error.config)에 설정됩니다.동시에 여러 API가 호출되는 경우:
GET /api/v1/users/me의 config 객체 → 각자의_retry플래그 보유POST /api/v1/groups/create의 config 객체 → 각자의_retry플래그 보유각 요청은 자체 config 객체를 가지므로, 서로 간섭하지 않습니다. 따라서
originalRequest._retry = true설정은 그 특정 요청에 대한 재시도만 방지합니다.2번 포인트에 대한 답변: 무한 루프 시나리오
코드를 다시 살펴보면:
무한 루프 발생 시나리오:
!originalRequest._retry체크 통과 (undefined)API.authService.refresh()호출 → 성공return baseAPI(originalRequest)- 요청 A 재시도!originalRequest._retry체크 (여전히 undefined) → 통과중요한 차이점:
API.authService.refresh()의{ _retry: true }→ refresh 엔드포인트 자체가 401을 받을 때만 보호originalRequest._retry = true→ 원래 실패한 요청(예: users/me)이 재시도 후 다시 401을 받을 때 보호이것이 표준적인 axios 인터셉터 refresh 패턴입니다. 대부분의 경우 문제없이 작동하지만, 엣지 케이스를 방지하기 위해
originalRequest._retry = true를 설정하는 것이 권장됩니다.혹시 제 설명에서 여전히 이해가 안 되는 부분이 있으시면 말씀해 주세요! 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
refresh api에서 정상적으로 200응답이 온 직후더라도 다시 401 에러가 발생하는 경우를 대비한 설정이라는 건가요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Chiman2937, 네, 정확히 이해하셨습니다! 👍
시나리오:
return baseAPI(originalRequest)실행 - 원래 요청 재시도이런 경우가 발생할 수 있는 상황:
결론:
originalRequest._retry = true설정은 이런 엣지 케이스를 방어하기 위한 안전장치입니다. 대부분의 경우 문제가 없지만, 예상치 못한 401 재발생 시 무한 루프를 확실하게 방지합니다.이것이 일반적인 axios 인터셉터 refresh 패턴에서 권장되는 이유입니다. 하지만 최종 결정은 팀의 판단에 맡기겠습니다! 😊