Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 24 minutes and 58 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe database service is refactored from email-specific to generic, store-parameterized operations. Configuration moves to a new structure, custom error classes are added, and the Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Warning
CodeRabbit couldn't request changes on this pull request because it doesn't have sufficient GitHub permissions.
Please grant CodeRabbit Pull requests: Read and write permission and re-run the review.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/services/database/index.ts (1)
91-115:⚠️ Potential issue | 🟠 Major
getBatch()cannot page safely on generic indexes.Line 101 uses a truthiness check that fails for valid cursor positions like
0and''; use an explicitstartCursor !== undefinedcheck instead. More critically, storing onlycursor.keyas the pagination token (line 109) is unreliable when an index has duplicate values—the next call cannot distinguish which record to resume from. Usecursor.continuePrimaryKey(key, primaryKey)with both the index key and primary key, or document this API as unique-index-only.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/services/database/index.ts` around lines 91 - 115, The getBatch implementation uses a truthy check for startCursor and stores only cursor.key which breaks for falsy keys (0, '') and duplicate index values; change the startCursor check in getBatch to explicit startCursor !== undefined, and switch pagination to a composite cursor: when iterating capture both cursor.key and cursor.primaryKey (use those as the pagination token nextCursor) and on subsequent calls resume using index.openCursor(...) with index.openCursor(null, 'prev') only when no startCursor, otherwise call cursor.continuePrimaryKey(startKey, startPrimaryKey) (or accept a composite startCursor type) so pagination is robust for non-unique indexes; update getBatch's return/param types to reflect the composite nextCursor.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/services/database/config/index.ts`:
- Around line 8-11: The indexes defined under EMAIL_DB_INDEXES_KEYS use
generateEmailParamPath('isRead'/'from'/'to') which resolve to non-IDBValidKey
types (boolean and User[]), so they won't populate; update the email record
shape to persist derived fields (e.g., add a numeric isReadFlag: 0|1 and string
arrays fromEmails/toEmails containing only email addresses) and change the index
keyPaths to generateEmailParamPath('isReadFlag'),
generateEmailParamPath('fromEmails'), and generateEmailParamPath('toEmails');
ensure the code that writes emails (the functions that set params.isRead,
params.from, params.to) maps those into the new derived fields before storing so
the indexes can use IDBValidKey types.
In `@src/services/database/database.service.test.ts`:
- Around line 13-21: The createRecord function merges default params but then
spreads overrides after, so passing overrides.params replaces the whole params
(dropping receivedAt); fix by extracting params from overrides first (e.g.,
const { params: paramsOverrides, ...rest } = overrides) and then build the
record with params: { receivedAt: ..., isRead: false, ...paramsOverrides } and
finally spread rest so non-params overrides apply without clobbering params;
update the createRecord helper (TestRecord factory) accordingly.
In `@src/services/database/types/index.ts`:
- Around line 54-70: The Database interface is missing the get method and
incorrectly types getBatch.startCursor as string|string[]; add a get signature
to match DatabaseService (e.g., get: <T>(storeName: string, key: IDBValidKey) =>
Promise<T | undefined>) and change the getBatch startCursor type from string |
string[] to IDBValidKey (or IDBValidKey | undefined) so the public contract uses
IDBValidKey like the concrete implementation; update the Database interface
entries for get and getBatch accordingly, referencing the existing getBatch and
other methods in src/services/database/types/index.ts.
---
Outside diff comments:
In `@src/services/database/index.ts`:
- Around line 91-115: The getBatch implementation uses a truthy check for
startCursor and stores only cursor.key which breaks for falsy keys (0, '') and
duplicate index values; change the startCursor check in getBatch to explicit
startCursor !== undefined, and switch pagination to a composite cursor: when
iterating capture both cursor.key and cursor.primaryKey (use those as the
pagination token nextCursor) and on subsequent calls resume using
index.openCursor(...) with index.openCursor(null, 'prev') only when no
startCursor, otherwise call cursor.continuePrimaryKey(startKey, startPrimaryKey)
(or accept a composite startCursor type) so pagination is robust for non-unique
indexes; update getBatch's return/param types to reflect the composite
nextCursor.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 7c79500a-115a-4d78-b7fd-3c4a34d8952c
📒 Files selected for processing (7)
src/errors/database/index.tssrc/services/database/config.tssrc/services/database/config/index.tssrc/services/database/config/utils.tssrc/services/database/database.service.test.tssrc/services/database/index.tssrc/services/database/types/index.ts
💤 Files with no reviewable changes (1)
- src/services/database/config.ts
|
2 participants
Decoupling the Email Store from the Database Service.