feat(sub2api): support opt-in check-in for compatible deployments - #1229
feat(sub2api): support opt-in check-in for compatible deployments#1229abkkkbb wants to merge 9 commits into
Conversation
Sub2API accounts previously reported check-in as unsupported: the adapter hardcoded `fetchSupportCheckIn` to false and no auto check-in provider was registered for the site type. Daily check-in is not part of Sub2API upstream mainline, so the capability is gated behind a new global preference (default off). While it is off nothing changes: no probe request is sent and detection stays force-disabled. Endpoint selection probes `/api/v1/check-in[/status]` first and falls back to `/api/v1/redeem/checkin[/status]`. An unauthenticated probe against a live deployment answered 401 for the former (route present, auth required) and the same bare `404 page not found` as an invented path for the latter, so the observed pair is tried first; the fallback covers forks that register check-in next to the redemption routes. Response handling degrades in four steps because deployments disagree on the payload shape: explicit boolean flag (deep key lookup, any nesting) -> last check-in date compared with today -> backend copy matching -> HTTP 409. Requests reuse the existing Sub2API JWT pipeline, so token refresh, 401 retry, and session re-sync are handled by `executeAuthenticatedSub2ApiRequest`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…at/sub2api-checkin
dosubot
Bot
added
the
size:XL
📄 Knowledge reviewDosu skipped reviewing this PR because your organization has used its
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds opt-in Sub2API check-in support with route probing, response parsing, provider integration, settings UI, localization, analytics fields, authentication-session persistence, and tests. ChangesSub2API check-in
Estimated code review effort: 4 (Complex) | ~60 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
|
Preview build ready for commit Artifacts:
This build is for review only and is not released. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tests/services/productAnalytics/autoCheckin.test.ts (1)
40-56: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winMap
sub2apiEnabledinto the config snapshot
AutoCheckinPreferences.sub2apiEnabledis an opt-in Auto Check-in setting, butbuildAutoCheckinConfigSnapshotProperties()does not include it in the snapshot payload, so the tests only coverfalsedefaults. Add an explicit snapshot mapping for this setting, or document that it is intentionally omitted.🤖 Prompt for 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. In `@tests/services/productAnalytics/autoCheckin.test.ts` around lines 40 - 56, Update the snapshot construction around buildAutoCheckinConfigSnapshotProperties to explicitly map the AutoCheckinPreferences sub2apiEnabled value into the generated config snapshot, and ensure the test verifies the enabled opt-in case rather than only the false default.Source: Coding guidelines
🧹 Nitpick comments (2)
src/services/checkin/sub2apiCheckinPreference.ts (1)
24-34: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDuplicate default-fallback for
autoCheckinpreferences.
preferences.autoCheckin ?? DEFAULT_PREFERENCES.autoCheckin!mirrors the identical fallback inAutoCheckinSettings.tsx. Per coding guidelines, this fallback should be normalized once at the preferences boundary (e.g., a sharedgetAutoCheckinPreferences()helper inuserPreferences.tsthat always returns a fully-populated object) rather than repeated at each call site.As per coding guidelines: "Normalize data at the highest reliable boundary and use required downstream types instead of repeatedly adding optional fallbacks; keep fallback behavior near the owning contract."
🤖 Prompt for 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. In `@src/services/checkin/sub2apiCheckinPreference.ts` around lines 24 - 34, Move the autoCheckin default normalization into the userPreferences boundary by adding or reusing a getAutoCheckinPreferences() helper that returns a fully populated settings object. Update isSub2ApiCheckinEnabled and AutoCheckinSettings.tsx to consume that helper directly, removing their local DEFAULT_PREFERENCES fallback while preserving the existing disabled-on-error behavior.Source: Coding guidelines
src/features/BasicSettings/components/tabs/CheckinRedeem/AutoCheckinSettings.tsx (1)
234-243: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winCentralize the Sub2API settings target ID.
The UI and search registry currently duplicate
"auto-checkin-sub2api-enable", so a future rename can silently break search navigation or deep links.
src/features/BasicSettings/components/tabs/CheckinRedeem/AutoCheckinSettings.tsx#L234-L243: use the shared exported target-ID constant for theCardItem.src/features/BasicSettings/components/tabs/CheckinRedeem/CheckinRedeem.search.ts#L42-L55: import and use the same constant forbuildControlDefinition.As per coding guidelines, settings UI target IDs should use one exported target-ID constant and be updated together.
🤖 Prompt for 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. In `@src/features/BasicSettings/components/tabs/CheckinRedeem/AutoCheckinSettings.tsx` around lines 234 - 243, The Sub2API settings target ID is duplicated between the UI and search registry. Export a shared target-ID constant and use it for the CardItem in AutoCheckinSettings.tsx (lines 234-243) and buildControlDefinition in CheckinRedeem.search.ts (lines 42-55), importing the constant where needed so both remain synchronized.Source: Coding guidelines
🤖 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 `@src/services/apiService/sub2api/checkin.ts`:
- Around line 5-10: The protocol comment must match the actual probe order:
update the description near SUB2API_CHECKIN_ROUTES to state that the older
/api/v1/check-in[/status] pair is attempted first, with redeem-scoped routes
used as the fallback on missing-route responses.
In `@tests/services/apiService/sub2api/checkin.test.ts`:
- Around line 66-78: Freeze Vitest system time in the “falls back to comparing
the last check-in date with today” test before constructing today and running
assertions, then restore real timers in afterEach. Keep the existing
parseSub2ApiCheckinPayload assertions unchanged.
---
Outside diff comments:
In `@tests/services/productAnalytics/autoCheckin.test.ts`:
- Around line 40-56: Update the snapshot construction around
buildAutoCheckinConfigSnapshotProperties to explicitly map the
AutoCheckinPreferences sub2apiEnabled value into the generated config snapshot,
and ensure the test verifies the enabled opt-in case rather than only the false
default.
---
Nitpick comments:
In
`@src/features/BasicSettings/components/tabs/CheckinRedeem/AutoCheckinSettings.tsx`:
- Around line 234-243: The Sub2API settings target ID is duplicated between the
UI and search registry. Export a shared target-ID constant and use it for the
CardItem in AutoCheckinSettings.tsx (lines 234-243) and buildControlDefinition
in CheckinRedeem.search.ts (lines 42-55), importing the constant where needed so
both remain synchronized.
In `@src/services/checkin/sub2apiCheckinPreference.ts`:
- Around line 24-34: Move the autoCheckin default normalization into the
userPreferences boundary by adding or reusing a getAutoCheckinPreferences()
helper that returns a fully populated settings object. Update
isSub2ApiCheckinEnabled and AutoCheckinSettings.tsx to consume that helper
directly, removing their local DEFAULT_PREFERENCES fallback while preserving the
existing disabled-on-error behavior.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: a1ebf1b7-6ae7-45d3-9da4-6117e4de7547
📒 Files selected for processing (31)
src/features/AutoCheckin/utils/autoCheckin.tssrc/features/BasicSettings/components/tabs/CheckinRedeem/AutoCheckinSettings.tsxsrc/features/BasicSettings/components/tabs/CheckinRedeem/CheckinRedeem.search.tssrc/locales/en/autoCheckin.jsonsrc/locales/en/messages.jsonsrc/locales/es-419/autoCheckin.jsonsrc/locales/es-419/messages.jsonsrc/locales/ja/autoCheckin.jsonsrc/locales/ja/messages.jsonsrc/locales/vi/autoCheckin.jsonsrc/locales/vi/messages.jsonsrc/locales/zh-CN/autoCheckin.jsonsrc/locales/zh-CN/messages.jsonsrc/locales/zh-TW/autoCheckin.jsonsrc/locales/zh-TW/messages.jsonsrc/services/accountSiteDefinitions/definitions.tssrc/services/apiService/sub2api/checkin.tssrc/services/apiService/sub2api/index.tssrc/services/checkin/autoCheckin/providers/index.tssrc/services/checkin/autoCheckin/providers/shared.tssrc/services/checkin/autoCheckin/providers/sub2api.tssrc/services/checkin/sub2apiCheckinPreference.tssrc/services/preferences/userPreferences.tssrc/types/autoCheckin.tstests/entrypoints/options/AutoCheckinSettings.test.tsxtests/entrypoints/options/AutoCheckinStatusCard.test.tsxtests/services/apiService/sub2api/checkin.test.tstests/services/autoCheckin/providers/sub2api.test.tstests/services/configMigration/preferences/preferencesMigration.test.tstests/services/productAnalytics/autoCheckin.test.tstests/services/productAnalytics/settings.test.ts
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
tests/services/productAnalytics/settings.test.ts (1)
155-155: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winCover the enabled aggregate path.
This test only verifies
auto_checkin_sub2api_enabled: false. Add a focused case withautoCheckin.sub2apiEnabled: trueand assertauto_checkin_sub2api_enabled: true; otherwise an incorrect source mapping or hardcodedfalsewould remain undetected. As per coding guidelines, executable logic changes should normally include targeted Vitest tests covering meaningful behavior and relevant edge cases.Also applies to: 500-500
🤖 Prompt for 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. In `@tests/services/productAnalytics/settings.test.ts` at line 155, Extend the relevant product analytics settings test around the existing sub2api-disabled case with a focused enabled case using autoCheckin.sub2apiEnabled set to true. Assert that the resulting auto_checkin_sub2api_enabled value is true, covering the aggregate mapping in both states.Source: Coding guidelines
🤖 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 `@src/services/productAnalytics/privacy.ts`:
- Line 416: Add “sub2api_enabled” to the allowlist used by
trackAutoCheckinConfigSnapshot’s SettingsSnapshotCaptured event, while retaining
the existing “auto_checkin_sub2api_enabled” entry so both direct and aggregate
snapshot keys are preserved.
---
Nitpick comments:
In `@tests/services/productAnalytics/settings.test.ts`:
- Line 155: Extend the relevant product analytics settings test around the
existing sub2api-disabled case with a focused enabled case using
autoCheckin.sub2apiEnabled set to true. Assert that the resulting
auto_checkin_sub2api_enabled value is true, covering the aggregate mapping in
both states.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 77a3b4e2-d2e2-450c-ae01-71e6e040c943
📒 Files selected for processing (14)
src/features/BasicSettings/components/tabs/CheckinRedeem/AutoCheckinSettings.tsxsrc/features/BasicSettings/components/tabs/CheckinRedeem/CheckinRedeem.search.tssrc/features/BasicSettings/components/tabs/CheckinRedeem/targetIds.tssrc/services/apiService/sub2api/checkin.tssrc/services/productAnalytics/autoCheckin.tssrc/services/productAnalytics/contracts.tssrc/services/productAnalytics/privacy.tssrc/services/productAnalytics/settings.tstests/features/AccountManagement/components/AccountDialog/sitePolicy.test.tstests/features/AccountManagement/hooks/useAccountDialog.redetectPreservesCustomData.test.tsxtests/features/AccountManagement/hooks/useAccountDialog.sub2apiConstraints.test.tsxtests/services/apiService/sub2api/checkin.test.tstests/services/productAnalytics/autoCheckin.test.tstests/services/productAnalytics/settings.test.ts
🚧 Files skipped from review as they are similar to previous changes (4)
- src/features/BasicSettings/components/tabs/CheckinRedeem/CheckinRedeem.search.ts
- src/features/BasicSettings/components/tabs/CheckinRedeem/AutoCheckinSettings.tsx
- tests/services/productAnalytics/autoCheckin.test.ts
- tests/services/apiService/sub2api/checkin.test.ts
| "managed_site_model_sync_allowed_models_configured", | ||
| "managed_site_model_sync_global_filters_configured", | ||
| "auto_checkin_global_enabled", | ||
| "auto_checkin_sub2api_enabled", |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Allow the key emitted by the direct snapshot producer.
trackAutoCheckinConfigSnapshot in src/services/productAnalytics/autoCheckin.ts emits sub2api_enabled with SettingsSnapshotCaptured, but this allowlist only adds auto_checkin_sub2api_enabled. The sanitizer therefore drops the new direct snapshot field. Add sub2api_enabled to this event’s allowlist while retaining the prefixed aggregate key.
🤖 Prompt for 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.
In `@src/services/productAnalytics/privacy.ts` at line 416, Add “sub2api_enabled”
to the allowlist used by trackAutoCheckinConfigSnapshot’s
SettingsSnapshotCaptured event, while retaining the existing
“auto_checkin_sub2api_enabled” entry so both direct and aggregate snapshot keys
are preserved.
|
为什么总关闭PR呢？ |
|
I'm sorry about some changes before. |
Sub2API rotates refresh tokens single-use and invalidates the previous one the moment it is exchanged, so any renewal a client performs must be written back or the stored token is burned. Two paths dropped the rotated pair: - The auto check-in provider and the check-in support probe in refreshAccount built requests without the sub2apiAuthSession port, so persistSub2ApiAuthUpdate silently no-opped. A daily check-in (manual or scheduled) renews the ~24h access token, then discards the new pair, leaving storage holding a token the server already revoked. The next run fails and the account asks for re-authorization. - Browser-session re-sync returned only the access token, so recovery restored at most one token lifetime and never the ability to renew headlessly again, making the failure unrecoverable without manual re-identification. Carry the refresh token through re-sync and attach the auth-session port on both check-in paths. Upstream contract: https://github.com/Wei-Shaw/sub2api
The check-in feature exposes supportsBuiltInCheckInDetection for Sub2API (gated at runtime by the global opt-in) and adds sub2api_enabled to the auto check-in config snapshot, but four suites still asserted the pre-feature shape and failed in CI. Update the product-profile, registry, scheduler snapshot, and account dialog expectations to the current capability.
# Conflicts: # src/services/accounts/accountStorage.ts # tests/services/productAnalytics/settings.test.ts
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/services/apiService/sub2api/index.ts (1)
1294-1343: 🚀 Performance & Scalability | 🔵 Trivial | 🏗️ Heavy liftAvoid probing check-in routes twice per refresh cycle.
fetchSupportCheckIn(Line 1301) andfetchCheckInStatus(Line 1326) each callprobeSub2ApiCheckinStatusindependently. Both request the same candidate routes and both derive from the same underlying payload (isCheckedInToday).In
src/services/accounts/accountStorage.ts,refreshAccountcallsaccountRefresh.fetchCheckInSupport(which resolves tofetchSupportCheckIn) and thenaccountRefresh.refreshAccount(which resolves torefreshAccountData→resolveSub2ApiCheckInConfig→fetchCheckInStatus) in the same refresh cycle. This means every refresh of a Sub2API account with check-in opted in probes the check-in endpoint twice, and each probe can itself issue up to two HTTP requests (one per candidate route) before finding the served route.Cache or share the
probeSub2ApiCheckinStatusresult within a single refresh cycle so support detection and status detection do not each trigger a full network probe. For example,fetchCheckInSupportcould return the probe result (or the derived status) soresolveSub2ApiCheckInConfigcan reuse it instead of probing again.🤖 Prompt for 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. In `@src/services/apiService/sub2api/index.ts` around lines 1294 - 1343, The Sub2API check-in support and status flows independently invoke probeSub2ApiCheckinStatus during one refresh cycle. Share or cache that probe result for the cycle, updating fetchSupportCheckIn and the downstream resolveCheckInSiteStatus/resolveSub2ApiCheckInConfig path as needed so status detection reuses the existing payload while preserving the current boolean and undefined contracts.
🤖 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 `@src/services/apiService/sub2api/index.ts`:
- Around line 1226-1245: Update fetchSub2ApiRawBody to fetch the unnormalized
Sub2API response by using fetchApi with normal-response handling disabled, or
the equivalent raw-response helper. Preserve executeAuthenticatedSub2ApiRequest
and ensure parseSub2ApiCheckinPayload receives the original success/message/data
envelope, including nested check-in fields.
---
Nitpick comments:
In `@src/services/apiService/sub2api/index.ts`:
- Around line 1294-1343: The Sub2API check-in support and status flows
independently invoke probeSub2ApiCheckinStatus during one refresh cycle. Share
or cache that probe result for the cycle, updating fetchSupportCheckIn and the
downstream resolveCheckInSiteStatus/resolveSub2ApiCheckInConfig path as needed
so status detection reuses the existing payload while preserving the current
boolean and undefined contracts.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 961556e2-3043-4177-b5cd-dd4318a1c320
📒 Files selected for processing (15)
src/locales/en/messages.jsonsrc/locales/es-419/messages.jsonsrc/locales/ja/messages.jsonsrc/locales/vi/messages.jsonsrc/locales/zh-CN/messages.jsonsrc/locales/zh-TW/messages.jsonsrc/services/accounts/accountStorage.tssrc/services/apiService/sub2api/index.tssrc/services/apiService/sub2api/tokenResync.tssrc/services/checkin/autoCheckin/providers/index.tssrc/services/checkin/autoCheckin/providers/sub2api.tssrc/services/preferences/userPreferences.tssrc/services/productAnalytics/contracts.tssrc/services/productAnalytics/privacy.tssrc/services/productAnalytics/settings.ts
🚧 Files skipped from review as they are similar to previous changes (12)
- src/locales/vi/messages.json
- src/locales/ja/messages.json
- src/locales/zh-CN/messages.json
- src/locales/es-419/messages.json
- src/services/productAnalytics/privacy.ts
- src/services/productAnalytics/contracts.ts
- src/locales/en/messages.json
- src/locales/zh-TW/messages.json
- src/services/preferences/userPreferences.ts
- src/services/productAnalytics/settings.ts
- src/services/checkin/autoCheckin/providers/index.ts
- src/services/checkin/autoCheckin/providers/sub2api.ts
| type Sub2ApiCheckinProbe = { | ||
| route: Sub2ApiCheckinRoute | ||
| payload: Sub2ApiCheckinPayload | ||
| } | ||
|
|
||
| /** | ||
| * Execute a Sub2API endpoint with full JWT handling and return the raw envelope. | ||
| * | ||
| * Check-in responses are interpreted by heuristics in `./checkin` rather than | ||
| * `parseSub2ApiEnvelope`, because a repeated check-in is reported as a non-zero | ||
| * envelope code (or HTTP 409) that must not surface as a hard failure. | ||
| */ | ||
| const fetchSub2ApiRawBody = async ( | ||
| request: ApiServiceRequest, | ||
| endpoint: string, | ||
| options: RequestInit, | ||
| ): Promise<unknown> => | ||
| executeAuthenticatedSub2ApiRequest(request, endpoint, (authRequest) => | ||
| fetchApi<unknown>(authRequest, { endpoint, options }, true), | ||
| ) |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Inspect extractDataFromApiResponseBody and isApiResponseBody behavior.
set -euo pipefail
rg -n -C 8 'function extractDataFromApiResponseBody|function isApiResponseBody' src/services/apiTransport/request.tsRepository: qixing-jk/all-api-hub
Length of output: 159
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== candidate files =="
git ls-files | rg '(^|/)src/(services/apiService/sub2api/index\.ts|services/apiTransport/request\.ts|constants/siteType\.ts)' || true
echo
echo "== fetchSub2ApiRawBody and imports/context =="
sed -n '1200,1280p' src/services/apiService/sub2api/index.ts
echo
echo "== fetchApi definitions/usages =="
rg -n -C 5 'const fetchApi|function fetchApi|export const fetchApi|export function fetchApi|extractDataFromApiResponseBody|isApiResponseBody|new.*fetchApi<unknown>|fetchApi<unknown>' src/services src/constants 2>/dev/null || trueRepository: qixing-jk/all-api-hub
Length of output: 17444
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== sub2api check-in routes and parsing =="
rg -n -C 5 'SUB2API_CHECKIN_ROUTES|parseSub2ApiCheckinPayload|isSub2ApiAlreadyCheckedError|fetchSub2ApiRawBody|/api/v1/(check-in|redeem/checkin)' src/services/apiService/sub2api src/services/checkin
echo
echo "== checkin payload implementation files =="
fd -a 'checkin|Checkin' src/services/checkin src/services/apiService/sub2api | sed 's#^\./##'
echo
echo "== request helper type and response implementation =="
sed -n '320,580p' src/services/apiTransport/request.ts
sed -n '1,90p' src/services/apiTransport/response.ts
echo
echo "== fetchApi implementation =="
sed -n '756,788p' src/services/apiTransport/request.tsRepository: qixing-jk/all-api-hub
Length of output: 23145
🌐 Web query:
sub2api check-in /api/v1/check-in response success message data
💡 Result:
Based on the technical documentation for the sub2api platform, there is no /api/v1/check-in endpoint [1][2]. The sub2api system explicitly does not support a check-in feature for user accounts [3]. In related integration contexts, it has been noted that the platform does not expose a compatible check-in endpoint, which often results in the disabling of such features in external clients or UI wrappers [3]. The sub2api User API endpoints, which are prefixed with /api/v1/, are primarily focused on profile management, API key handling, and usage tracking [1][2]. Standard successful responses in the sub2api system follow a consistent format, typically handled by internal response helpers (e.g., response.Success) that return JSON data containing the requested resource or status information [4]. If you are encountering a response message for a check-in request, it is likely not part of the official sub2api core API contract [2].
Citations:
- 1: https://deepwiki.com/Wei-Shaw/sub2api/8.2-user-api
- 2: https://deepwiki.com/Wei-Shaw/sub2api/8-api-reference
- 3: feat(sub2api): add key management support for sub2api accounts #572
- 4: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/backend/internal/handler/auth_handler.go
🌐 Web query:
"Wei-Shaw" sub2api "checkin" "code" "Already checked"
💡 Result:
In the context of the Wei-Shaw/sub2api project, a check-in code refers to a mechanism for daily user attendance and reward systems [1]. The "Already checked" status indicates that the user or account has successfully completed the daily check-in process for the current day, preventing duplicate check-ins and duplicate rewards [1]. Key aspects of this feature include: Daily Check-in Functionality: The feature allows users to perform a daily check-in through the platform to earn rewards (such as points or account balance) [1]. System Logic: When a user attempts to check in, the system verifies the current check-in status [1]. If the check-in has already been performed for the current date, the system returns a message confirming that the account is "Already checked" (or equivalent, depending on the localization) to prevent abuse [1]. Implementation: This functionality is handled on the backend through specific API endpoints, and the status is tracked in the system's database to maintain state across sessions [1]. Management: Administrators have access to configuration options to define check-in rewards and view check-in status for accounts via the admin dashboard [1]. Additionally, related tools like "all-api-hub" also integrate with these systems to manage and automate such check-in processes for relay accounts [2][3][4]. If you are encountering an "Already checked" message, it simply confirms that the action has already been successfully executed for today [1].
Citations:
- 1: feat: 添加每日签到功能 Wei-Shaw/sub2api#510
- 2: e3bce39
- 3: 28b3f66
- 4: https://skillsllm.com/skill/all-api-hub
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== parseSub2ApiCheckinPayload implementation =="
sed -n '170,260p' src/services/apiService/sub2api/checkin.ts
echo
echo "== known Sub2API response helper names =="
rg -n 'Success|Data|Response|checkin|already check|code in' src/services/apiService/sub2api src/services/checkin || true
echo
echo "== all-api-hub checked-in behavior in issue context (local repo issue mentions) =="
rg -n -i '572|already checked|check-in|checkin' src README.md package.json 2>/dev/null || trueRepository: qixing-jk/all-api-hub
Length of output: 50378
🌐 Web query:
"sub2api" "data": { "reward" | "isCheckedInToday" | "success" | "message"
💡 Result:
The data structure you referenced is associated with the Daily Check-in functionality implemented in the Sub2API platform [1]. This feature allows users to perform a daily check-in to receive rewards, such as balance or points [1]. In the context of Sub2API and related management tools (like All-API-Hub which tracks check-in status for such platforms) [2][3], the structure appears to be a response object from the check-in API endpoint [1][2]. Based on technical implementation details from the Sub2API codebase and integration modules, the response typically includes the following fields [1][2]: - reward: The amount or type of benefit granted (e.g., credit/balance) upon a successful check-in [1]. - isCheckedInToday: A boolean flag indicating whether the user has already completed the check-in for the current day [2]. - success: A boolean indicating whether the API request was successful [2]. - message: A string providing feedback or status information (e.g., "ok", "Already checked in", or error descriptions) [2]. This data is used by the frontend to update the user's check-in status, show the reward received, and provide appropriate notifications [1][2]. Administrative settings in Sub2API allow administrators to define these rewards [1].
Citations:
🌐 Web query:
Wei-Shaw/sub2api checkin data reward isCheckedInToday
💡 Result:
In the context of Wei-Shaw/sub2api, isCheckedInToday is a boolean status flag associated with the daily check-in feature [1]. This feature, introduced to the sub2api platform, allows users to perform daily check-ins to receive rewards such as credits or balance [1]. Key points regarding this field: 1. Origin and Purpose: The daily check-in functionality, including the tracking of check-in status, was implemented to enhance user engagement by providing a mechanism to earn rewards [1]. The backend provides API interfaces to manage these check-ins, while the frontend displays the status and provides a button for users [1]. 2. Reliability and Usage: In external management tools like All API Hub, which integrate with sub2api and other similar platforms, the isCheckedInToday flag is sometimes considered unreliable for determining whether to execute an automated check-in [2]. Instead, these tools often prefer to rely on direct responses from the upstream provider (e.g., an already_checked status) to confirm if a check-in has already been successfully performed [2]. 3. Data Structure: Within the system's configuration and DTO (Data Transfer Object) schemas, isCheckedInToday exists within check-in configuration structures (often nested under siteStatus or customCheckIn) to track whether a user has already checked in for the current day [3][4]. If you are developing or debugging code involving this field, note that external tools have specifically addressed bugs related to the default values of this flag [5] and have implemented logic to preserve this custom check-in data during account re-detection or sync processes [3][6].
Citations:
- 1: feat: 添加每日签到功能 Wei-Shaw/sub2api#510
- 2: https://all-api-hub.qixing1217.top/auto-checkin.html
- 3: 28b3f66
- 4: https://github.com/jlwebs/AllApiDeck/blob/44196dde40ecc708084a22db283414ada6af7abc/tmp_log_utf8.txt
- 5: https://github.com/qixing-jk/all-api-hub/blob/main/docs/docs/changelog.md
- 6: feat(navigation): add bulk external check-in functionality #344
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== exact Sub2API check-in-related fields in local payload/parser =="
rg -n -C 3 'isCheckedInToday|Reward|reward|Already checked|already checked|ALREADY_CHECKED_STATUS_CODE|extractSub2ApiCheckinMessage' src/services/apiService/sub2api/checkin.ts
echo
echo "== fetchViaCurrentTabContent implementation =="
rg -n -C 4 'fetchViaCurrentTabContent|parseResponseByType|onlyData:.*true|onlyData: undefined|onlyData' src/services/apiTransport/request.ts | head -n 120Repository: qixing-jk/all-api-hub
Length of output: 6234
🌐 Web query:
Wei-Shaw sub2api daily check-in Response Success data isCheckedInToday reward
💡 Result:
The daily check-in feature in the Wei-Shaw sub2api platform allows users to earn rewards by performing a daily sign-in [1]. This feature, introduced in early 2026, includes backend API endpoints, service layer logic, and a database schema to handle check-in status and reward distribution [1]. Regarding the specific terms requested: 1. isCheckedInToday: This is a boolean field within the check-in configuration and status data structures [2][3]. It indicates whether a user has already performed their check-in for the current day [2]. Systems often use this field in conjunction with date tracking to prevent duplicate check-ins [4][2]. 2. Response Success data: The API endpoints related to user activities, such as daily usage or check-ins, typically return a structured JSON response [5][6]. A successful response is standardly wrapped in an object containing a code and a data payload [6], where the data field contains the requested information (e.g., check-in success status, reward details, or usage items) [5][4]. 3. Reward: Administrators can configure specific rewards (such as platform balance or credits) that are issued to users upon a successful daily check-in [1]. It is important to note that while isCheckedInToday is a standard field used to track state, some implementations caution that it may not always be the sole source of truth [4]. Developers sometimes prefer to rely on server-side responses from upstream providers (often indicated by flags like already_checked) to verify the actual success of a check-in event [4].
Citations:
- 1: feat: 添加每日签到功能 Wei-Shaw/sub2api#510
- 2: 28b3f66
- 3: 0655288
- 4: https://all-api-hub.qixing1217.top/auto-checkin.html
- 5: Wei-Shaw/sub2api@51f7218
- 6: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/frontend/src/types/index.ts
🌐 Web query:
site:github.com/Wei-Shaw/sub2api checkin controller data isCheckedInToday reward success message
💡 Result:
In the context of the sub2api project, the "daily check-in" feature was implemented to allow users to earn rewards, such as balance or points [1]. While your query specifically asks about isCheckedInToday and its associated "reward success message" within a controller, the current implementation of this system follows patterns found in the project's existing redeem and user service modules [2][3][4]. Based on the architectural implementation of similar features (like the redeem code system), you can expect the following flow for a daily check-in controller: 1. Request Validation: The controller handles the incoming check-in request, likely triggered by a user action in the personal center [1]. 2. Logic Execution: A dedicated service layer (e.g., CheckinService) verifies the check-in status (isCheckedInToday logic) to prevent duplicate rewards within the same day [1]. 3. Reward Issuance: If the user has not checked in, the service issues the configured reward [1]. 4. Success Response: The controller returns a JSON response containing the success status and a message [5][6]. In this codebase, success messages are often handled via frontend toast notifications (e.g., appStore.showSuccess(t('...'))) triggered by the returned API message [5][7]. If you are implementing this, ensure your backend service returns a clear message field in the response body, which the frontend can then interpret and display to the user as a success toast [6][4]. Consistent with other parts of the system, this logic should be wrapped in an idempotent service layer to prevent double-claiming [2][4].
Citations:
- 1: feat: 添加每日签到功能 Wei-Shaw/sub2api#510
- 2: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/backend/internal/service/redeem_service.go
- 3: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/backend/internal/handler/user_handler.go
- 4: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/backend/internal/handler/admin/redeem_handler.go
- 5: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/frontend/src/views/user/RedeemView.vue
- 6: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/frontend/src/api/redeem.ts
- 7: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/frontend/src/views/admin/RedeemView.vue
Use a raw Sub2API envelope for check-in probing.
Sub2API check-in responses can follow success, message, and data, for example with nested isCheckedInToday and reward. fetchSub2ApiRawBody currently calls fetchApi<unknown>(..., true), so this normalizes that shape before parseSub2ApiCheckinPayload() receives it. Use a helper that does not pass _normalResponseType, or call fetchApi<unknown>(..., false) for these endpoints, so ./checkin sees the raw body.
🤖 Prompt for 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.
In `@src/services/apiService/sub2api/index.ts` around lines 1226 - 1245, Update
fetchSub2ApiRawBody to fetch the unnormalized Sub2API response by using fetchApi
with normal-response handling disabled, or the equivalent raw-response helper.
Preserve executeAuthenticatedSub2ApiRequest and ensure
parseSub2ApiCheckinPayload receives the original success/message/data envelope,
including nested check-in fields.
UpdateMerged latest 1. Found a real bug while using the feature: Sub2API rotates refresh tokens Two paths dropped the rotated pair:
2. Validation: |
main added the pt-BR locale, which lacked the Sub2API check-in keys this
branch introduces, so locale validation and i18n:extract:ci failed on the
merged result.
Translate the three missing keys, following the es-419 wording and the
pt-BR settings tab name ("Check-in e resgate") for the guidance path.
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/locales/pt-BR/autoCheckin.json (1)
1-223: 📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick winRe-run locale extraction and synchronized locale updates.
The changed
src/locales/pt-BR/autoCheckin.jsonandsrc/locales/pt-BR/messages.jsonkeys do not match the sibling locale key sets, so extraction/sync updates are still needed. Use the required progressive validation after extraction:
pnpm run validate:stagedpnpm run validate:pushwhen handoff/commit is reached.🤖 Prompt for 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. In `@src/locales/pt-BR/autoCheckin.json` around lines 1 - 223, Re-run locale extraction and synchronize the key sets for src/locales/pt-BR/autoCheckin.json and src/locales/pt-BR/messages.json with their sibling locales; update both files as required by the extraction output, then run pnpm run validate:staged and run pnpm run validate:push when handoff or commit is reached.Source: Coding guidelines
🤖 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.
Outside diff comments:
In `@src/locales/pt-BR/autoCheckin.json`:
- Around line 1-223: Re-run locale extraction and synchronize the key sets for
src/locales/pt-BR/autoCheckin.json and src/locales/pt-BR/messages.json with
their sibling locales; update both files as required by the extraction output,
then run pnpm run validate:staged and run pnpm run validate:push when handoff or
commit is reached.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: bdda6ea4-3908-4a90-bf14-3e8bec5ab388
📒 Files selected for processing (2)
src/locales/pt-BR/autoCheckin.jsonsrc/locales/pt-BR/messages.json
…shold codecov/patch flagged 87.42% of the diff (target 95.07%); every miss was a fallback/error branch rather than a code change. Close them: - sub2apiApiService index: cover the global opt-in on paths — support probe, can-check-in resolution, probe-missing-route fallback, already-checked probe, and the check-in POST rethrow — plus account-data config resolution with detection on and off. - checkin helpers: locate a flag inside array payloads (findValue recursion). - check-in preference: storage read failure degrades to disabled. - auto-checkin utils: translate the sub2apiDisabled fallback key. - auto check-in settings: persist the Sub2API opt-in toggle. - sub2api provider: succeed with no backend message or reward (local copy).
There was a problem hiding this comment.
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 `@tests/services/apiService/sub2api/index.test.ts`:
- Around line 66-78: Re-apply the false default for mockIsSub2ApiCheckinEnabled
after each vi.restoreAllMocks() in the broader describe blocks. Update the
relevant beforeEach hooks, or explicitly reset this mock there, while preserving
the opt-in describe block’s ability to override it to true.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: ad088725-65ac-4b1e-907f-8028278a4bd2
📒 Files selected for processing (6)
tests/entrypoints/options/AutoCheckinSettings.test.tsxtests/features/AutoCheckin/utils/autoCheckin.test.tstests/services/apiService/sub2api/checkin.test.tstests/services/apiService/sub2api/index.test.tstests/services/autoCheckin/providers/sub2api.test.tstests/services/checkin/sub2apiCheckinPreference.test.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- tests/services/apiService/sub2api/checkin.test.ts
| const { mockIsSub2ApiCheckinEnabled } = vi.hoisted(() => ({ | ||
| mockIsSub2ApiCheckinEnabled: vi.fn(), | ||
| })) | ||
|
|
||
| vi.mock("~/services/checkin/sub2apiCheckinPreference", () => ({ | ||
| isSub2ApiCheckinEnabled: mockIsSub2ApiCheckinEnabled, | ||
| })) | ||
|
|
||
| // Most tests in this file exercise Sub2API with check-in opt-in off (the | ||
| // upstream default), so the probe never runs and no extra `fetchApi` calls are | ||
| // made. The opt-in-on describe block at the end flips this back on. | ||
| mockIsSub2ApiCheckinEnabled.mockResolvedValue(false) | ||
|
|
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check whether earlier beforeEach hooks reset mocks in a way
# that could clobber the module-level mockIsSub2ApiCheckinEnabled default.
rg -n 'restoreAllMocks|resetAllMocks|mockIsSub2ApiCheckinEnabled' tests/services/apiService/sub2api/index.test.tsRepository: qixing-jk/all-api-hub
Length of output: 530
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== file size =="
wc -l tests/services/apiService/sub2api/index.test.ts
echo "== top-level mock setup =="
sed -n '50,85p' tests/services/apiService/sub2api/index.test.ts
echo "== first prior beforeEach with restoreAllMocks =="
sed -n '610,645p' tests/services/apiService/sub2api/index.test.ts
echo "== second prior beforeEach with restoreAllMocks =="
sed -n '1435,1455p' tests/services/apiService/sub2api/index.test.ts
echo "== opt-in describe block =="
sed -n '2728,2754p' tests/services/apiService/sub2api/index.test.ts
echo "== nearby tests around first reset =="
sed -n '645,690p' tests/services/apiService/sub2api/index.test.tsRepository: qixing-jk/all-api-hub
Length of output: 5412
Re-assert the isSub2ApiCheckinEnabled default after mock resets.
mockIsSub2ApiCheckinEnabled.mockResolvedValue(false) is overwritten by the vi.restoreAllMocks() in the broader describe blocks, because the later beforeEaches do not reset it. Move this default setup into those beforeEach hooks, or add an explicit reset for this mock, so the opt-out value is not lost by cleanup.
🤖 Prompt for 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.
In `@tests/services/apiService/sub2api/index.test.ts` around lines 66 - 78,
Re-apply the false default for mockIsSub2ApiCheckinEnabled after each
vi.restoreAllMocks() in the broader describe blocks. Update the relevant
beforeEach hooks, or explicitly reset this mock there, while preserving the
opt-in describe block’s ability to override it to true.
|
Thanks for the work and for exploring this idea. The investigation confirms that some Sub2API-derived deployments do provide daily check-in, so the underlying use case is valuable. After reviewing the complete implementation, we have decided not to merge or request further revisions to this PR. The required changes are no longer incremental. The current implementation treats several fork-specific endpoints as one inferred Sub2API-compatible protocol, and mixes global opt-in, deployment capability, account configuration, protocol selection, and daily status. Correcting this would require replacing the current product model and restructuring most of the integration rather than applying a bounded review fix. In particular:
We may revisit the idea separately as a generic account-level check-in method system:
The existing custom check-in URL will remain a separate bookmark-like feature. No further code changes are needed on this branch. We will close this PR in favor of reconsidering the feature through that narrower design. The endpoint research and the findings around Sub2API token rotation were still useful—thank you for contributing them. |
|
One follow-up question about protocol provenance only — no further code changes are being requested on this PR. We found a public source for the redeem-scoped variant:
Could you clarify the source of the other route pair and the additional response aliases used by this PR?
The code comment says that a live deployment returned HTTP 401 for the
For response samples, the useful cases would be: enabled but not checked in, disabled, successful check-in, already checked in, and an ordinary failure. It would also help to know the authentication form and HTTP status used in each case, and which aliases were actually observed versus added defensively. Please do not include access tokens, refresh tokens, cookies, authorization headers, account identifiers, or private deployment details. This information will help us evaluate the first adapters proposed in #1270 without treating inferred fields as a shared protocol. |
2 participants
Summary
/api/v1/check-inand/api/v1/redeem/checkinendpoint variants across different forksresponse formats
tests
Screenshots
Sub2API check-in opt-in
The setting defaults to off because daily check-in is not available in upstream
Sub2API and is supported only by compatible deployments or forks.
Validation
pnpm run i18n:extract:cipnpm run validate:stagedSummary by CodeRabbit