🔀 :: (#952) 토큰 재발급 중복 호출 문제 해결

[ashxom]

개요

refresh token의 중복 사용으로 로그아웃되는 문제를 방지하고 토큰 재발급 로직의 안정성을 개선했습니다.

작업사항

• 동시 401 응답 발생 시 토큰 재발급이 중복 호출되지 않도록 수정
• 이미 갱신된 access token이 있으면 재발급 없이 재사용하도록 변경
• 세션 갱신 성공 여부를 유효한 access token 기준으로 판단하도록 수정

추가 로 할 말

Summary by CodeRabbit

• Refactor
  • Improved cached token and session refresh behavior to align outcomes with current token availability.
  • Streamlined authorization handling so refreshed credentials only replace the request header when needed.
• Bug Fixes
  • Improved network response resource handling during token reissue to prevent leaks and ensure consistent failure behavior.
• Security
  • Strengthened validation to avoid unnecessary authorization header updates when a refresh does not produce a new token.

[coderabbitai]

Warning

Review limit reached

@ashxom, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 38 minutes and 46 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 3923093e-44a8-45cc-967f-b58187e89660

📥 Commits

Reviewing files that changed from the base of the PR and between d1238f8 and d874995.

📒 Files selected for processing (2)

• core/jwt/src/main/java/team/aliens/dms/android/core/jwt/network/authenticator/JwtAuthenticator.kt
• core/jwt/src/main/java/team/aliens/dms/android/core/jwt/network/interceptor/JwtInterceptor.kt

📝 Walkthrough

Walkthrough

Refactors JwtProviderImpl token getter expressions, availability StateFlow backing fields, and session resolution boolean return conditions. Updates JwtReissueManager to annotate its URL parameter with @TokenReissueUrl and wrap the HTTP response in a use {} block. Reworks JwtAuthenticator to capture the failed authorization header and skip redundant token refreshes when a newer cached token already exists.

Changes

JWT Core Refactor

Layer / File(s)	Summary
Token getters and availability state flows core/jwt/.../JwtProviderImpl.kt	cachedAccessToken and cachedRefreshToken getters rewritten with local val bindings and null/expiry throws; _isCachedAccessTokenAvailable and _isCachedRefreshTokenAvailable refactored as backing MutableStateFlows exposed via asStateFlow(); loadTokens() assigns cached fields directly and calls refreshTokenAbility() after load.
Session resolution and refresh return logic core/jwt/.../JwtProviderImpl.kt	resolveSession() and refreshSession() converted to withLock expression bodies; return condition changed from checkIsAccessTokenAvailable() || checkIsRefreshTokenAvailable() to reissued && checkIsAccessTokenAvailable(); resolveSession() short-circuits with true for non-expired cached access tokens; availability check helpers simplified to nullable-safe expressions.
Token reissue, persistence, and rollback core/jwt/.../JwtProviderImpl.kt	reissueTokensLocked() calls jwtReissueManager with refreshToken.value, catches CannotReissueTokenException on 401/404 by invoking clearCachesLocked(); updateTokensLocked() and clearCachesLocked() reformatted with direct _cached* assignments, preserving rollback pattern and IllegalStateException throws on persistence failure.
JwtReissueManager URL qualifier and response resource management core/jwt/.../network/JwtReissueManager.kt	Constructor parameter annotated with @TokenReissueUrl; OkHttp execute() call wrapped in response.use {} to guarantee response closure; private helpers for body deserialization and request construction restructured for readability without behavioral change.
JwtAuthenticator retry de-duplication and ignore logic core/jwt/.../network/authenticator/JwtAuthenticator.kt	authenticate() captures failedAuthorization header and skips header update when refreshAuthorization returns the same value; refreshAuthorization(failedAuthorization) short-circuits to cached token when it already differs from the failed header, otherwise refreshes session; shouldBeIgnored rewritten with explicit path/method/isIgnoredRequest variables; checkS3Request converted to expression body.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• team-aliens/DMS-Android#828: Modifies JwtProviderImpl token availability/refresh and JwtReissueManager reissue/exception handling, which directly overlaps with the same classes changed in this PR.
• team-aliens/DMS-Android#877: Changes JwtProviderImpl.reissueTokens() error handling for CannotReissueTokenException (cache clearing on 401 vs 401/404), directly intersecting with this PR's reissueTokensLocked/clearCachesLocked refactor.
• team-aliens/DMS-Android#908: Modifies JwtProviderImpl's refreshSession/session-resolution boolean logic and JwtAuthenticator's refresh/authorization retry behavior, covering the same code paths changed here.

Poem

🐇 Hoppity-hop through token land,
No more stale auth slipping through my hand!
The cached bearer meets its failed twin,
A use {} block keeps responses thin.
reissued && available — what a neat gate,
This bunny's JWT flow is finally great! 🔐

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly addresses the main objective: preventing duplicate token reissuance calls. It matches the core purpose of the changeset.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch bug/952-토큰-재발급-중복-호출-문제-해결

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@core/jwt/src/main/java/team/aliens/dms/android/core/jwt/network/authenticator/JwtAuthenticator.kt`:
- Around line 77-86: The checkS3Request(url.toString()) call is currently placed
inside the any() lambda predicate, which means it will never be evaluated if
ignoreRequests.requests is empty since the any() function short-circuits without
executing the lambda. Move the S3 request check outside of the any() loop in the
shouldBeIgnored() method so that checkS3Request is always evaluated
independently, allowing S3 requests to be properly ignored regardless of whether
there are other ignore requests configured.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: b8c0415b-fb5d-4cd1-b915-66d99d97a4eb

📥 Commits

Reviewing files that changed from the base of the PR and between 5a7007a and eb71c5d.

📒 Files selected for processing (3)

• core/jwt/src/main/java/team/aliens/dms/android/core/jwt/JwtProviderImpl.kt
• core/jwt/src/main/java/team/aliens/dms/android/core/jwt/network/JwtReissueManager.kt
• core/jwt/src/main/java/team/aliens/dms/android/core/jwt/network/authenticator/JwtAuthenticator.kt