feat: tightened the RefreshToken response type

[DanielRivers]

Explain your changes

Update the RefreshTokenResult to be more explict on the data to be reponded with on success or failure

Checklist

• I have read the “Pull requests” section in the contributing guidelines.
• I agree to the terms within the code of conduct.

🛟 If you need help, consider asking for advice over in the Kinde community.

[coderabbitai]

Walkthrough

Replaces the single RefreshTokenResult interface with a discriminated union comprising RefreshTokenResultError and RefreshTokenResultSuccess, then exports RefreshTokenResult as their union; other public exports remain unchanged.

Changes

Cohort / File(s)	Summary of Changes
Type refactor: RefreshTokenResult lib/types.ts	Removed the previous RefreshTokenResult interface; added RefreshTokenResultError (success: false, error?: string, token fields excluded) and RefreshTokenResultSuccess (success: true, error?: never, token fields allowed); introduced RefreshTokenResult = RefreshTokenResultError | RefreshTokenResultSuccess and updated exports.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• feat(types): export RefreshType #120 — Also modifies RefreshTokenResult in lib/types.ts; closely related type evolution.
• feat: notify on token refresh after code exchange #104 — Adds an onRefresh callback typed with RefreshTokenResult; will be affected by the union change.
• feat: add onRefreshHandler to custom handle token refreshes #172 — Adjusts onRefreshHandler / refresh flows that consume RefreshTokenResult; directly impacted by the new union.

Suggested reviewers

• Yoshify

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title succinctly captures the primary change by specifying that the RefreshToken response type has been tightened. This directly corresponds to the updates splitting the RefreshTokenResult interface into explicit success and error variants. The phrasing is concise, clear, and follows standard pull request naming conventions.
Description Check	✅ Passed	The pull request description clearly states that RefreshTokenResult has been updated to explicitly differentiate success and failure response data. This directly matches the changeset modifying the RefreshTokenResult union type. The content is concise and fully on-topic, satisfying the lenient description requirement.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/updateRefreshTokenType

---

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.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

lib/types.ts (1)

255-261: Require all token fields in RefreshTokenResultSuccess
The refresh handler always returns accessToken, idToken, and refreshToken when success: true, so remove ? from those properties in the interface.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a6a12a5 and e1465ff.

📒 Files selected for processing (1)

• lib/types.ts (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

lib/types.ts (1)

lib/main.ts (1)

• StorageKeys (72-72)

🔇 Additional comments (2)

lib/types.ts (2)

247-253: Optional error field is intentional: keeping error?: string supports cases without error messages (e.g., test mocks), so no change needed.

---

263-265: Discriminated union implementation is correct; confirm external callers check success
Internal code only produces or forwards the union with no unsafe property access; since this is a breaking change, manually verify all external consumers check success before accessing other properties.