Conversation
|
Warning Review limit reached
Your plan includes 1 review of capacity. Refill in 45 minutes and 26 seconds. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more review capacity refills, 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 trial, open-source, and free plans. In all cases, review capacity refills continuously over time. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (11)
📝 WalkthroughWalkthroughRedis configuration is migrated from separate host/port/db/password environment variables to a single REDIS_URL value. A new centralized redis.ts module exports the client using the URL-based configuration, replacing all direct env.redisConnection references throughout queue infrastructure and endpoint integrations. ChangesRedis Configuration and Client Consolidation
🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 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.
Actionable comments posted: 5
🤖 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 @.github/workflows/_install.yml:
- Line 15: The checkout step currently uses actions/checkout@v4 without
disabling credential persistence; update the GitHub Actions step that references
uses: actions/checkout@v4 to include persist-credentials: false so the checkout
action does not store the workflow token for later steps/artifacts, reducing
token exposure risk.
- Around line 15-18: Pin the mutable GitHub Action versions by replacing uses:
actions/checkout@v4 with uses:
actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 and add with:
persist-credentials: false to lock down checkout credentials, and replace uses:
actions/setup-node@v4 with uses:
actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020; additionally update
the install step (if present) to use npm ci instead of npm i --ignore-scripts
for deterministic CI installs (ensure package-lock.json is committed).
- Line 24: The workflow uses "run: npm i --ignore-scripts" which is
non-deterministic; either commit a generated package-lock.json and change the
step to use "npm ci --ignore-scripts" (so CI uses the lockfile) or switch the
step to the repository's actual package manager and immutable install command
(e.g., "yarn install --immutable" if a yarn.lock exists); update the run line in
.github/workflows/_install.yml accordingly so the install command matches the
committed lockfile.
In @.github/workflows/format.yml:
- Around line 18-24: The format job ("format") currently depends on "install"
but runs in a fresh runner and lacks checkout/Node/deps, so add the missing
setup steps before running "npm run format-check": include actions/checkout,
actions/setup-node (matching the project's Node version), and the install step
used in "install" (e.g., npm ci or npm install) or alternatively invoke the
reusable workflow input that runs the formatting inside the install workflow;
update the "format" job to include these steps (checkout, setup-node, install)
or call the reusable workflow's formatting command so the runner has the source
and dependencies before the npm run format-check step.
🪄 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: f8aacc23-da0c-4a68-8dff-f395603460bf
📒 Files selected for processing (7)
.github/workflows/_install.yml.github/workflows/ci.yml.github/workflows/coverage-pages.yml.github/workflows/format.yml.github/workflows/lint.yml.github/workflows/release.yml.github/workflows/test.yml
💤 Files with no reviewable changes (1)
- .github/workflows/ci.yml
| runs-on: ubuntu-latest | ||
| steps: | ||
| - name: Checkout code | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
Disable credential persistence in checkout.
Line 15 should set persist-credentials: false to reduce token exposure risk in later steps/artifacts.
Suggested fix
- name: Checkout code
uses: actions/checkout@v4
+ with:
+ persist-credentials: false📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| uses: actions/checkout@v4 | |
| - name: Checkout code | |
| uses: actions/checkout@v4 | |
| with: | |
| persist-credentials: false |
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 14-15: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 15-15: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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 @.github/workflows/_install.yml at line 15, The checkout step currently uses
actions/checkout@v4 without disabling credential persistence; update the GitHub
Actions step that references uses: actions/checkout@v4 to include
persist-credentials: false so the checkout action does not store the workflow
token for later steps/artifacts, reducing token exposure risk.
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Setup Node.js | ||
| uses: actions/setup-node@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify current SHAs behind the major tags before pinning.
gh api repos/actions/checkout/git/ref/tags/v4 --jq '.object.sha'
gh api repos/actions/setup-node/git/ref/tags/v4 --jq '.object.sha'Repository: Billos/Sparkleft
Length of output: 142
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/_install.yml"
echo "== File exists =="
ls -la "$FILE" || exit 1
echo
echo "== Context around referenced lines =="
nl -ba "$FILE" | sed -n '1,120p' | sed -n '10,60p'
echo
echo "== Find checkout step configuration =="
rg -n "actions/checkout@|persist-credentials" "$FILE" || true
echo
echo "== Find npm install/build commands =="
rg -n "npm (i|install|ci)|npm run build" "$FILE" || true
echo
echo "== Full actions uses lines (quick scan) =="
rg -n "uses:\s+[^ ]+@v" "$FILE" || trueRepository: Billos/Sparkleft
Length of output: 258
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/_install.yml"
echo "== File content (with line numbers via awk) =="
awk '{printf "%4d:%s\n", NR, $0}' "$FILE" | sed -n '1,120p'
echo
echo "== Locate checkout/setup-node uses in file =="
rg -n "uses:\s+actions/(checkout|setup-node)@" "$FILE" || true
echo
echo "== Locate persist-credentials (if any) =="
rg -n "persist-credentials" "$FILE" || true
echo
echo "== Locate npm install/build commands =="
rg -n "npm (i|install|ci)" "$FILE" || true
rg -n "npm run build" "$FILE" || trueRepository: Billos/Sparkleft
Length of output: 986
🌐 Web query:
actions/checkout v4 default persist-credentials
💡 Result:
In the actions/checkout v4 action, the persist-credentials input defaults to true [1][2][3]. When persist-credentials is set to its default value of true, the action configures the local git repository with the authentication token (such as the GITHUB_TOKEN) used for the checkout [1][4][5]. This allows subsequent steps in the same job to perform authenticated git commands [1][2]. The token is automatically removed during the post-job cleanup phase [1][2]. Security best practices often recommend setting persist-credentials: false for workflows that do not require git push capabilities [5]. This reduces the attack surface by preventing other steps or potentially compromised dependencies from accessing the stored credentials in the local.git/config file [4][5][6]. To opt out of this behavior, you can explicitly set the input to false in your workflow configuration [1][4]: uses: actions/checkout@v4 with: persist-credentials: false
Citations:
- 1: https://github.com/actions/checkout/tree/v4
- 2: https://github.com/actions/checkout
- 3: https://github.com/actions/checkout/blob/v4/README.md
- 4: https://yossarian.net/til/post/actions-checkout-can-leak-github-credentials/
- 5: Add persist-credentials: false to GitHub Actions checkout steps aquasecurity/trivy#10305
- 6: Remove
persist-credentialsor change the default tofalseactions/checkout#485
🌐 Web query:
npm ci vs npm install deterministic in CI package-lock
💡 Result:
Use npm ci in CI for deterministic installs from package-lock.json. Why npm ci is deterministic (and what it does with package-lock.json) - npm ci is intended for automated environments like CI and “clean install” scenarios. It requires an existing package-lock.json (or npm-shrinkwrap.json). If dependencies in the lock do not match those in package.json, npm ci exits with an error instead of updating the lockfile. It also removes any existing node_modules before installing, and it “will never write to package.json or any of the package-locks: installs are essentially frozen.” [1][2] - By contrast, npm install uses package-lock.json only as long as it satisfies package.json ranges; if ranges don’t match, npm resolves new versions that satisfy package.json and updates package-lock.json accordingly. [3] Practical implication for “deterministic in CI package-lock” - If your CI runs npm install, it can rewrite/update package-lock.json when package.json ranges and the checked-in lockfile conflict (or when the lockfile is otherwise out of sync), so you can end up with a different dependency tree than the one you tested/reviewed. [3] - If your CI runs npm ci, it will install according to the locked versions and fail when package.json and package-lock.json aren’t in sync—preventing silent drift of the installed dependency graph. [1][2] Caveats to keep it working deterministically - npm ci expects the lockfile to be compatible with the flags/settings used to generate it (example: flags affecting dependency tree shape like --legacy-peer-deps). If you used such flags to create the package-lock, you must provide the same flags to npm ci or it may error. [1] Recommended CI command - npm ci Summary - npm ci is designed for reproducible/clean CI installs from a committed package-lock.json, while npm install may update the lockfile when package.json ranges and the lockfile don’t align—reducing determinism in CI. [1][2][3]
Citations:
- 1: https://docs.npmjs.com/cli/v9/commands/npm-ci/?v=true
- 2: https://www.unpkg.com/npm@9.6.7/docs/output/commands/npm-ci.html
- 3: https://docs.npmjs.com/cli/v10/commands/npm-ci/
🌐 Web query:
GitHub Actions security best practices pin actions to commit SHA
💡 Result:
Pinning GitHub Actions to a full-length commit SHA is a critical security best practice that ensures your workflows use an immutable version of an action [1][2][3]. Why Pinning to a Commit SHA is Recommended: - Immutability: Unlike tags (e.g., @v4) or branches (e.g., @main), which are mutable and can be updated or redirected by repository owners at any time, a commit SHA uniquely identifies a specific, unchangeable state of the code [1][2][4]. - Supply Chain Security: If an action's repository is compromised, an attacker could update a tag to point to malicious code. Workflows pinned to a specific SHA remain unaffected by such changes, protecting your environment from unauthorized code execution and potential credential theft [5][6][7]. - Reproducibility: Pinning guarantees that your workflows run the exact same code every time, which is essential for consistent builds, testing, and debugging [5]. How to Implement SHA Pinning: - Use the full 40-character commit SHA in your workflow file: uses: actions/checkout@11bd719 - To maintain readability and facilitate updates, it is common practice to include the original tag as a comment [8][5][9]: uses: actions/checkout@11bd719 # v4.2.2 Managing Updates: Because pinned SHAs do not update automatically, you should use dependency management tools like Dependabot or Renovate to monitor for updates and create pull requests when new versions are released [1][5][7]. Enforcement: GitHub allows administrators to enforce this practice at the organization or repository level [1][3][10]. When this policy is enabled, any workflow attempting to use an action referenced by a tag or branch will fail, ensuring that all dependencies meet your security standards [1][10]. Note that this policy applies to the entire dependency tree, including sub-actions [1].
Citations:
- 1: https://www.romainlespinasse.dev/posts/github-actions-commit-sha-pinning/
- 2: https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide
- 3: https://docs.github.com/en/actions/reference/security/secure-use
- 4: https://www.aikido.dev/blog/checklist-github-actions
- 5: https://blog.rafaelgss.dev/why-you-should-pin-actions-by-commit-hash
- 6: https://gbhackers.com/compromised-github-action/
- 7: Pin GitHub Actions to commit SHAs instead of version tags ankitects/anki#4722
- 8: https://github.com/mheap/pin-github-action
- 9: https://github.com/ihs7/action-sha-pinned-actions
- 10: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
Pin actions/checkout / actions/setup-node to commit SHAs (and lock down checkout credentials)
Lines 15 and 18 use mutable @v4 tags. Replace with immutable SHAs:
actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5and setwith: persist-credentials: false(default istrue).actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020.- Consider using
npm ciinstead ofnpm i --ignore-scriptsfor more deterministic CI installs (requirespackage-lock.json).
🧰 Tools
🪛 zizmor (1.25.2)
[error] 15-15: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 18-18: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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 @.github/workflows/_install.yml around lines 15 - 18, Pin the mutable GitHub
Action versions by replacing uses: actions/checkout@v4 with uses:
actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 and add with:
persist-credentials: false to lock down checkout credentials, and replace uses:
actions/setup-node@v4 with uses:
actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020; additionally update
the install step (if present) to use npm ci instead of npm i --ignore-scripts
for deterministic CI installs (ensure package-lock.json is committed).
| cache: "npm" | ||
|
|
||
| - name: Install dependencies | ||
| run: npm i --ignore-scripts |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Confirm lockfile exists before switching to npm ci.
fd -HI '^package-lock\.json$'Repository: Billos/Sparkleft
Length of output: 42
Fix deterministic CI install: npm ci requires a committed package-lock.json.
.github/workflows/_install.yml line 24 runs npm i --ignore-scripts, but there’s no package-lock.json in the repo; switching to npm ci --ignore-scripts would fail. Commit/generate package-lock.json and then use npm ci --ignore-scripts, or switch the workflow to the repo’s actual package manager for deterministic installs (e.g., yarn install --immutable if yarn.lock is used).
🤖 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 @.github/workflows/_install.yml at line 24, The workflow uses "run: npm i
--ignore-scripts" which is non-deterministic; either commit a generated
package-lock.json and change the step to use "npm ci --ignore-scripts" (so CI
uses the lockfile) or switch the step to the repository's actual package manager
and immutable install command (e.g., "yarn install --immutable" if a yarn.lock
exists); update the run line in .github/workflows/_install.yml accordingly so
the install command matches the committed lockfile.
| format: | ||
| name: Check Formatting | ||
| runs-on: ubuntu-latest | ||
| needs: install | ||
| steps: | ||
| - name: Check formatting | ||
| run: npm run format-check |
There was a problem hiding this comment.
format job cannot use artifacts/environment from install implicitly.
Line 18–24 runs in a fresh job, so it does not inherit checkout, Node setup, or installed deps from Line 15–16. This will fail at runtime. Run formatting inside the reusable workflow (via input command) or repeat setup steps in this job.
🤖 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 @.github/workflows/format.yml around lines 18 - 24, The format job ("format")
currently depends on "install" but runs in a fresh runner and lacks
checkout/Node/deps, so add the missing setup steps before running "npm run
format-check": include actions/checkout, actions/setup-node (matching the
project's Node version), and the install step used in "install" (e.g., npm ci or
npm install) or alternatively invoke the reusable workflow input that runs the
formatting inside the install workflow; update the "format" job to include these
steps (checkout, setup-node, install) or call the reusable workflow's formatting
command so the runner has the source and dependencies before the npm run
format-check step.
| install: | ||
| uses: ./.github/workflows/_install.yml | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify whether install/build artifacts are actually handed off to release.
set -euo pipefail
echo "== release.yml =="
sed -n '1,260p' .github/workflows/release.yml
echo
echo "== _install.yml =="
sed -n '1,260p' .github/workflows/_install.yml
echo
echo "== Search for dependency/artifact handoff and job dependency wiring =="
rg -n --type=yaml -C3 'needs:\s*install|upload-artifact|download-artifact|actions/cache|npm (ci|install|i)' .github/workflowsRepository: Billos/Sparkleft
Length of output: 4418
Fix release workflow to ensure dependencies are installed/handed off from install.
release runs npm test, npm run lint, and npm run format but has no needs: install and no dependency-install step. Even though install calls ./.github/workflows/_install.yml (which runs npm i + npm run build), there’s no artifact handoff (upload-artifact/download-artifact), so dependencies won’t be available to the release job.
Suggested fix
jobs:
install:
uses: ./.github/workflows/_install.yml
release:
+ needs: install
name: Release
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
@@
+ - name: Install dependencies
+ run: npm ci --ignore-scripts
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/endpoints/settingCategoryForTransaction.ts (1)
19-24:⚠️ Potential issue | 🟠 Major | ⚡ Quick winClose
queueEventsinsettingCategoryForTransactionto prevent lingering QueueEvents consumers
src/endpoints/settingCategoryForTransaction.tscreatesnew QueueEvents(...)(line ~19) and waits viajob.waitUntilFinished(queueEvents)(line ~23) but never callsawait queueEvents.close(), leaving the QueueEvents client/consumers alive.💡 Proposed fix
const queue = await getQueue() const queueEvents = new QueueEvents(queue.name, { connection }) const { transactionId, category_id } = req.params - const job = await addEndpointJobToQueue(new SetCategoryForTransactionJob(), transactionId, { category_id }) - await job.waitUntilFinished(queueEvents) - next() + try { + const job = await addEndpointJobToQueue(new SetCategoryForTransactionJob(), transactionId, { category_id }) + await job.waitUntilFinished(queueEvents) + next() + } finally { + await queueEvents.close() + } }🤖 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/endpoints/settingCategoryForTransaction.ts` around lines 19 - 24, The QueueEvents instance created with new QueueEvents(...) in settingCategoryForTransaction is never closed, leaving consumers alive; wrap the job.waitUntilFinished(queueEvents) call in a try/finally and in the finally block call await queueEvents.close() so the QueueEvents client is always closed (also handle/await any errors from waitUntilFinished); reference the QueueEvents instance, job.waitUntilFinished, addEndpointJobToQueue, and SetCategoryForTransactionJob when making the change.
🤖 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/endpoints/settingBudgetForTransaction.ts`:
- Line 19: The QueueEvents instantiation is passing env.redisUrl (a string) into
new QueueEvents(queue.name, { connection: env.redisUrl }) which causes a type
mismatch; import and use the shared ioredis client instance instead (e.g., the
exported redis/redisClient from your redis module) and pass that as the
connection option: new QueueEvents(queue.name, { connection: redisClient }).
Update the import at the top of the file to pull the shared ioredis instance and
remove usage of env.redisUrl for QueueEvents so the connection type matches
BullMQ's expected Redis client/options.
---
Outside diff comments:
In `@src/endpoints/settingCategoryForTransaction.ts`:
- Around line 19-24: The QueueEvents instance created with new QueueEvents(...)
in settingCategoryForTransaction is never closed, leaving consumers alive; wrap
the job.waitUntilFinished(queueEvents) call in a try/finally and in the finally
block call await queueEvents.close() so the QueueEvents client is always closed
(also handle/await any errors from waitUntilFinished); reference the QueueEvents
instance, job.waitUntilFinished, addEndpointJobToQueue, and
SetCategoryForTransactionJob when making the change.
🪄 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: c01fb93e-6017-48d5-a6bd-dcfa4fe40a26
📒 Files selected for processing (9)
.env.defaultsrc/config.tssrc/endpoints/settingBudgetForTransaction.tssrc/endpoints/settingCategoryForTransaction.tssrc/endpoints/triggerAutoImport.tssrc/endpoints/triggerBudgetSumUp.tssrc/queues/index.tssrc/queues/queue.tssrc/redis.ts
1 participant
Summary by CodeRabbit
Configuration
REDIS_URLenvironment variable instead of separate host, port, database, and password variables.Improvements