Conversation
Contributor
WalkthroughRefactors auth into modular handlers (login, register, verify), adds JWT/refresh config and crypto deps, creates an Changes
Sequence Diagram(s)sequenceDiagram
participant Client as Client
participant API as Auth API
participant DB as Database
participant Email as Email Service
Client->>API: POST /register {email, username, password}
API->>API: normalize & validate
API->>DB: INSERT user (hashed password)
DB-->>API: user created (id)
API->>Email: send verification email
alt email send succeeds
Email-->>API: OK
API-->>Client: 201 Created (check email)
else email send fails
Email-->>API: Error
API->>DB: DELETE user (compensate)
API-->>Client: 500 / Email error
end
sequenceDiagram
participant Client as Client
participant API as Auth API
participant DB as Database
Client->>API: POST /login {login, password}
API->>API: normalize & validate
API->>DB: SELECT user by email OR username
DB-->>API: User row
API->>API: spawn_blocking verify(password, hash)
alt password matches AND user.verified
API-->>Client: 200 OK ("Welcome!")
else invalid credentials
API-->>Client: 401 Unauthorized
else not verified
API-->>Client: 403 Forbidden
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
rust-server/src/config.rs (1)
50-59:⚠️ Potential issue | 🟠 MajorValidate auth secrets and TTLs during config load.
JWT_ACCESS_SECRET=andREFRESH_TOKEN_PEPPER=deserialize as empty strings, and TTLs can be0/negative. Add post-load validation for non-empty sufficiently long distinct secrets and positive TTLs before the app starts.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@rust-server/src/config.rs` around lines 50 - 59, After loading env into Config in Config::from_env, add post-deserialization validation: ensure jwt_access_secret and refresh_token_pepper are non-empty, meet a minimum length (choose a sensible constant, e.g. >=32), and are not identical to each other; also ensure jwt_access_ttl_seconds and refresh_ttl_seconds are positive (>0). If any check fails, return a descriptive Err from Config::from_env (propagate or convert to envy::Error or a custom error) so the application fails fast during startup; reference the Config struct fields jwt_access_secret, refresh_token_pepper, jwt_access_ttl_seconds, refresh_ttl_seconds and the Config::from_env function when making the changes.rust-server/src/db/queries.rs (1)
22-34: 🛠️ Refactor suggestion | 🟠 MajorAvoid
SELECT *in auth user lookups.These login queries only need a stable auth projection. Explicit columns avoid coupling
Usermapping to unrelated/futureuserscolumns and reduce accidental sensitive data loading.♻️ Proposed refactor
- sqlx::query_as::<_, User>("SELECT * FROM users WHERE email = $1") + sqlx::query_as::<_, User>( + "SELECT id, email, username, password, verified, created_at, updated_at FROM users WHERE email = $1", + ) .bind(email) .fetch_optional(db) .await .map_err(AppError::Sql) } @@ - sqlx::query_as::<_, User>("SELECT * FROM users WHERE username = $1") + sqlx::query_as::<_, User>( + "SELECT id, email, username, password, verified, created_at, updated_at FROM users WHERE username = $1", + ) .bind(username)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@rust-server/src/db/queries.rs` around lines 22 - 34, The login queries find_login_user_by_email and find_login_user_by_username currently use "SELECT *" which pulls all user columns (including sensitive/future fields); change both queries to select an explicit stable auth projection (e.g., id, username, email, password_hash, created_at — whatever fields your auth flow requires) instead of "*", and update the mapped type if necessary (create/use an AuthUser struct or adjust User to contain only those auth fields used by sqlx::query_as). Ensure both functions use the same explicit column list and that the struct field names/types match the selected columns so sqlx mapping succeeds.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@rust-server/migrations/20260422060250_create_auth_sessions_table.sql`:
- Around line 4-14: Add DB-level uniqueness to the auth_sessions table: make
refresh_token_hash unique and ensure rotated_from_id can only appear once (to
enforce single-use rotation). Add a UNIQUE constraint or unique index for
refresh_token_hash (e.g., UNIQUE(refresh_token_hash) or CREATE UNIQUE INDEX
idx_auth_sessions_refresh_token_hash_unique ON
auth_sessions(refresh_token_hash)) and add a unique index for rotated_from_id
that applies only to non-null values (e.g., CREATE UNIQUE INDEX
idx_auth_sessions_rotated_from_id_unique ON auth_sessions(rotated_from_id) WHERE
rotated_from_id IS NOT NULL) so rotation and token identity are enforced by the
database rather than application code.
In `@rust-server/src/features/auth/handlers/login.rs`:
- Around line 54-57: The login handler currently returns
Ok(ApiResponse::ok("Welcome!", None)) before issuing any tokens or persisting a
session; modify the function in login.rs to (1) generate an access token (e.g.,
call your token creation routine such as generate_access_token or create_jwt for
the authenticated user id), (2) create/persist an auth session row (call
save_auth_session / insert_auth_session with user id, refresh token, expiry,
client metadata), and (3) attach the refresh token to the response as a secure
HttpOnly cookie (use your set_refresh_token_cookie helper) and include the
access token in the response body instead of the plain "Welcome!" message;
ensure these steps occur before returning Ok(ApiResponse::ok(...)).
In `@rust-server/src/features/auth/handlers/register.rs`:
- Around line 38-59: The pre-checks using find_user_by_email and
find_user_by_username are TOCTOU-prone; keep or remove them but ensure the
insert path (new_user) handles DB unique-constraint races by catching the DB
error and converting it to AppError::conflict. Modify new_user (or the call site
wrapping its Result) to match the database error code/message for
unique-constraint violations and return Err(AppError::conflict("Email already in
use")) or Err(AppError::conflict("Username already in use")) as appropriate;
leave other DB errors mapped to AppError::internal. Ensure you reference the
unique constraint identifiers from the DB error to distinguish email vs username
violations.
- Around line 61-77: The handler is performing a best-effort compensating delete
after the user was already committed, which can leave a stuck unverified account
if deletion fails; instead remove the delete_user compensating logic and
implement an outbox/retry or idempotent resend flow: stop deleting in
register.rs (remove the delete_user(...) call and the early Err(return
email_err)), enqueue the verification email via an outbox queue or schedule a
retry from state.email.send_verification_email (or return a success registration
response while marking the account unverified and ensure a
resend_verification_token endpoint can generate and deliver a token on demand),
and ensure state.config.app_env.is_test() logic is preserved so tests still
bypass the outbox.
In `@rust-server/src/features/auth/handlers/verify.rs`:
- Around line 83-92: The code currently calls update_verification_token(db,
user.get("id")) and persists the new token before
state.email.send_verification_email(...) which means a send failure leaves the
stored token unusable; change the flow so the persisted token is only replaced
after a successful send (or, if you must persist pre-send, fetch and keep the
old token and restore it on send failure). Concretely: generate the new token
but do not call update_verification_token until send_verification_email
succeeds, or call update_verification_token but save the previous token (read
current value) and on Err(email_err) restore the old token in the DB; use the
existing functions update_verification_token and
state.email.send_verification_email and ensure errors from the email send do not
leave the DB with an unused token.
In `@rust-server/src/features/auth/service.rs`:
- Around line 37-43: The function find_login_user currently returns
AppError::not_found when no user is found, which leaks account existence; change
the error to a generic auth failure by returning an unauthorized error instead
(e.g., AppError::unauthorized("Invalid credentials")). Update the ok_or_else
call in find_login_user (after calling find_login_user_by_email or
find_login_user_by_username) to use AppError::unauthorized with a neutral
message so missing users and bad passwords yield the same response.
In `@rust-server/src/types.rs`:
- Around line 1-15: The User struct currently derives Debug and Serialize which
can leak password hashes; remove Debug and Serialize from the derive list on the
internal DB row type (keep FromRow and Deserialize/other DB traits as needed)
and create a separate safe DTO (e.g., PublicUser or UserResponse) that includes
only id, email, username, verified, created_at, updated_at and derives
Serialize/Debug for API responses; ensure the original User.password remains
absent from any serializable/loggable struct and update code paths that return
User to instead map/convert to the safe DTO (referencing the struct name User
and the new DTO name you add).
---
Outside diff comments:
In `@rust-server/src/config.rs`:
- Around line 50-59: After loading env into Config in Config::from_env, add
post-deserialization validation: ensure jwt_access_secret and
refresh_token_pepper are non-empty, meet a minimum length (choose a sensible
constant, e.g. >=32), and are not identical to each other; also ensure
jwt_access_ttl_seconds and refresh_ttl_seconds are positive (>0). If any check
fails, return a descriptive Err from Config::from_env (propagate or convert to
envy::Error or a custom error) so the application fails fast during startup;
reference the Config struct fields jwt_access_secret, refresh_token_pepper,
jwt_access_ttl_seconds, refresh_ttl_seconds and the Config::from_env function
when making the changes.
In `@rust-server/src/db/queries.rs`:
- Around line 22-34: The login queries find_login_user_by_email and
find_login_user_by_username currently use "SELECT *" which pulls all user
columns (including sensitive/future fields); change both queries to select an
explicit stable auth projection (e.g., id, username, email, password_hash,
created_at — whatever fields your auth flow requires) instead of "*", and update
the mapped type if necessary (create/use an AuthUser struct or adjust User to
contain only those auth fields used by sqlx::query_as). Ensure both functions
use the same explicit column list and that the struct field names/types match
the selected columns so sqlx mapping succeeds.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: 5a49742b-06c4-40ed-9384-8b13959a20f3
⛔ Files ignored due to path filters (1)
rust-server/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (17)
rust-server/.env_examplerust-server/Cargo.tomlrust-server/migrations/20260422060250_create_auth_sessions_table.sqlrust-server/src/config.rsrust-server/src/db/queries.rsrust-server/src/errors.rsrust-server/src/features/auth/handlers.rsrust-server/src/features/auth/handlers/login.rsrust-server/src/features/auth/handlers/mod.rsrust-server/src/features/auth/handlers/register.rsrust-server/src/features/auth/handlers/verify.rsrust-server/src/features/auth/routes.rsrust-server/src/features/auth/service.rsrust-server/src/lib.rsrust-server/src/main.rsrust-server/src/types.rsrust-server/tests/api/common.rs
💤 Files with no reviewable changes (1)
- rust-server/src/features/auth/handlers.rs
Contributor
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)
rust-server/compose.yml (1)
10-18:⚠️ Potential issue | 🟠 MajorUse the production DB name for the main
postgresservice.Line 10 initializes the main database as
${DB_TEST_NAME}, but Line 18 healthchecks${DB_NAME}. If those differ, the main DB container can stay unhealthy even though Postgres started correctly.🐛 Proposed fix
- POSTGRES_DB: ${DB_TEST_NAME} + POSTGRES_DB: ${DB_NAME}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@rust-server/compose.yml` around lines 10 - 18, The compose file sets POSTGRES_DB to ${DB_TEST_NAME} while the healthcheck runs pg_isready against ${DB_NAME}, causing a mismatch; update the POSTGRES_DB entry to use ${DB_NAME} (or alternatively make the healthcheck use ${DB_TEST_NAME}) so the service's database name and the healthcheck target are the same—change the POSTGRES_DB environment variable in the postgres service to reference ${DB_NAME} and ensure the healthcheck test (the pg_isready -U ${POSTGRES_USER} -d ${DB_NAME} command) matches that same variable.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@rust-server/compose.yml`:
- Around line 11-14: The compose.yml currently injects JWT_ACCESS_SECRET,
JWT_ACCESS_TTL_SECONDS, REFRESH_TOKEN_PEPPER, and REFRESH_TTL_SECONDS into the
Postgres service even though rust-server/src/config.rs::Config::from_env() reads
these in the Rust app; remove those variables from the Postgres service and add
them to the Rust application service's environment block so the Rust
container/runtime receives the secrets (ensure names match Config::from_env
expectations and any duplicate entries at lines 32-35 are moved as well).
---
Outside diff comments:
In `@rust-server/compose.yml`:
- Around line 10-18: The compose file sets POSTGRES_DB to ${DB_TEST_NAME} while
the healthcheck runs pg_isready against ${DB_NAME}, causing a mismatch; update
the POSTGRES_DB entry to use ${DB_NAME} (or alternatively make the healthcheck
use ${DB_TEST_NAME}) so the service's database name and the healthcheck target
are the same—change the POSTGRES_DB environment variable in the postgres service
to reference ${DB_NAME} and ensure the healthcheck test (the pg_isready -U
${POSTGRES_USER} -d ${DB_NAME} command) matches that same variable.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: a93ca77f-554d-45a6-96f5-699562292ce6
📒 Files selected for processing (1)
rust-server/compose.yml
Comment on lines
+11
to
+14
| JWT_ACCESS_SECRET: ${JWT_ACCESS_SECRET} | ||
| JWT_ACCESS_TTL_SECONDS: ${JWT_ACCESS_TTL_SECONDS} | ||
| REFRESH_TOKEN_PEPPER: ${REFRESH_TOKEN_PEPPER} | ||
| REFRESH_TTL_SECONDS: ${REFRESH_TTL_SECONDS} |
Contributor
There was a problem hiding this comment.
Move auth secrets out of the Postgres containers.
These JWT/refresh values are read by rust-server/src/config.rs::Config::from_env() in the Rust app process, not by PostgreSQL. Keeping them here both fails to configure the app container/runtime and unnecessarily exposes auth secrets to DB containers.
🔐 Proposed fix
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
POSTGRES_DB: ${DB_NAME}
- JWT_ACCESS_SECRET: ${JWT_ACCESS_SECRET}
- JWT_ACCESS_TTL_SECONDS: ${JWT_ACCESS_TTL_SECONDS}
- REFRESH_TOKEN_PEPPER: ${REFRESH_TOKEN_PEPPER}
- REFRESH_TTL_SECONDS: ${REFRESH_TTL_SECONDS} POSTGRES_USER: ${POSTGRES_USER}
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
POSTGRES_DB: ${DB_TEST_NAME}
- JWT_ACCESS_SECRET: ${JWT_ACCESS_SECRET}
- JWT_ACCESS_TTL_SECONDS: ${JWT_ACCESS_TTL_SECONDS}
- REFRESH_TOKEN_PEPPER: ${REFRESH_TOKEN_PEPPER}
- REFRESH_TTL_SECONDS: ${REFRESH_TTL_SECONDS}Add these variables to the Rust application service/runtime instead.
Also applies to: 32-35
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@rust-server/compose.yml` around lines 11 - 14, The compose.yml currently
injects JWT_ACCESS_SECRET, JWT_ACCESS_TTL_SECONDS, REFRESH_TOKEN_PEPPER, and
REFRESH_TTL_SECONDS into the Postgres service even though
rust-server/src/config.rs::Config::from_env() reads these in the Rust app;
remove those variables from the Postgres service and add them to the Rust
application service's environment block so the Rust container/runtime receives
the secrets (ensure names match Config::from_env expectations and any duplicate
entries at lines 32-35 are moved as well).
Contributor
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)
.github/workflows/tests.yml (1)
60-161: 🧹 Nitpick | 🔵 TrivialRecommended refactor: the
rust-backendande2ejobs now share ~18 env vars — DRY them up before it bites you.Here's a trick every senior learns the hard way: whenever you copy-paste a block of config into two CI jobs, the next person (probably future-you) will update one and forget the other, and you'll burn an afternoon chasing "works in rust-backend, fails in e2e" ghosts. You've now got two large, identical
env:blocks (lines 60–80 vs 140–160), and every new auth/config field will need to be added in both places.GitHub Actions doesn't support YAML anchors, but you have two idiomatic escape hatches:
- Reusable workflow (
workflow_call) — factor the shared env + postgres service into.github/workflows/_backend-setup.ymland call it from both jobs. Cleanest long-term.- Composite action (
./.github/actions/setup-backend-env) — a local action whoseenvoutput youecho ... >> $GITHUB_ENVinto each job. Lighter-weight.Not a blocker for this PR, but worth an issue on your backlog — this file is going to keep growing as you add features.
Want me to draft the reusable-workflow version so you can see the shape of it?
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/tests.yml around lines 60 - 161, The rust-backend and e2e jobs duplicate ~18 identical env variables (and the postgres service) causing maintenance drift; refactor by extracting the shared env + postgres service into a reusable workflow (e.g., create a new workflow that declares workflow_call and exposes the env and service configuration) or a composite action that writes the env to GITHUB_ENV, then update the rust-backend and e2e jobs to call that reusable workflow/action (referencing the job names rust-backend and e2e and the duplicated env blocks) and keep only job-specific vars like NEXT_PUBLIC_DEV_BACKEND in the calling job.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/tests.yml:
- Around line 75-78: The TTL values are not secret and should not be pulled from
secrets; replace uses of JWT_ACCESS_TTL_SECONDS and REFRESH_TTL_SECONDS in the
workflow with plain values or non-secret vars (e.g., hardcode 600 and 604800 or
use ${{ vars.JWT_ACCESS_TTL_SECONDS }} / ${{ vars.REFRESH_TTL_SECONDS }}), and
update both jobs where JWT_ACCESS_TTL_SECONDS and REFRESH_TTL_SECONDS are
currently set as secrets so logs aren’t masked and CI is reproducible.
In `@client/playwright.config.ts`:
- Line 36: Replace the hardcoded command string in the Playwright config's
command property ("bun --bun next dev") with an npm script invocation so the
config uses the project's single source of truth; change the value to call the
package.json dev script (e.g., "bun run dev" or "npm run dev" depending on your
project) so updates to scripts.dev automatically apply to Playwright's launch
behavior and avoid drift between Playwright's command and scripts.dev.
---
Outside diff comments:
In @.github/workflows/tests.yml:
- Around line 60-161: The rust-backend and e2e jobs duplicate ~18 identical env
variables (and the postgres service) causing maintenance drift; refactor by
extracting the shared env + postgres service into a reusable workflow (e.g.,
create a new workflow that declares workflow_call and exposes the env and
service configuration) or a composite action that writes the env to GITHUB_ENV,
then update the rust-backend and e2e jobs to call that reusable workflow/action
(referencing the job names rust-backend and e2e and the duplicated env blocks)
and keep only job-specific vars like NEXT_PUBLIC_DEV_BACKEND in the calling job.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: 4ef986d1-1f53-43a1-9b55-7884bfb157c2
⛔ Files ignored due to path filters (1)
client/bun.lockis excluded by!**/*.lock
📒 Files selected for processing (3)
.github/workflows/tests.ymlclient/package.jsonclient/playwright.config.ts
Comment on lines
+75
to
+78
| JWT_ACCESS_SECRET: ${{ secrets.JWT_ACCESS_SECRET }} | ||
| JWT_ACCESS_TTL_SECONDS: ${{ secrets.JWT_ACCESS_TTL_SECONDS }} | ||
| REFRESH_TOKEN_PEPPER: ${{ secrets.REFRESH_TOKEN_PEPPER }} | ||
| REFRESH_TTL_SECONDS: ${{ secrets.REFRESH_TTL_SECONDS }} |
Contributor
There was a problem hiding this comment.
Minor: TTLs don't need to be secrets — only the key material does.
Mentor-mode on 🎓 — secrets should be reserved for things whose disclosure would harm you. JWT_ACCESS_SECRET and REFRESH_TOKEN_PEPPER absolutely qualify (they're the openssl rand -hex 64 outputs per rust-server/.env_example). But JWT_ACCESS_TTL_SECONDS and REFRESH_TTL_SECONDS are just integers (600 and 604800 in the example file) — policy, not secret. Stashing them in GitHub Secrets has two downsides:
- They get masked in logs, making CI debugging harder when a token expires "mysteriously."
- Anyone reading the workflow can't tell what values CI actually runs with, so reproducing a failure locally becomes guesswork.
Prefer hardcoding them (or pulling from vars if you want them tunable without a code change):
🛠️ Suggested change (apply in both jobs)
- JWT_ACCESS_TTL_SECONDS: ${{ secrets.JWT_ACCESS_TTL_SECONDS }}
+ JWT_ACCESS_TTL_SECONDS: "600"
REFRESH_TOKEN_PEPPER: ${{ secrets.REFRESH_TOKEN_PEPPER }}
- REFRESH_TTL_SECONDS: ${{ secrets.REFRESH_TTL_SECONDS }}
+ REFRESH_TTL_SECONDS: "604800"Or, if you like them configurable: ${{ vars.JWT_ACCESS_TTL_SECONDS }}.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/tests.yml around lines 75 - 78, The TTL values are not
secret and should not be pulled from secrets; replace uses of
JWT_ACCESS_TTL_SECONDS and REFRESH_TTL_SECONDS in the workflow with plain values
or non-secret vars (e.g., hardcode 600 and 604800 or use ${{
vars.JWT_ACCESS_TTL_SECONDS }} / ${{ vars.REFRESH_TTL_SECONDS }}), and update
both jobs where JWT_ACCESS_TTL_SECONDS and REFRESH_TTL_SECONDS are currently set
as secrets so logs aren’t masked and CI is reproducible.
| // playwright.config.ts | ||
| { | ||
| command: "bun run dev", | ||
| command: "bun --bun next dev", |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Nit: consider invoking the npm script instead of inlining the command.
A little mentor wisdom 🧙 — whenever you can, route through your package.json scripts (bun run dev) rather than hardcoding the command here. Why? Single source of truth: if tomorrow you add a flag (say --turbo, a custom port, or an env loader) to the dev script, your Playwright config will silently drift out of sync. Inlining is fine when you deliberately want a different dev command for e2e — but right now it's identical to scripts.dev in client/package.json, so the indirection costs nothing and buys you consistency.
♻️ Suggested tweak
- command: "bun --bun next dev",
+ command: "bun run dev",📝 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.
Suggested change
| command: "bun --bun next dev", | |
| command: "bun run dev", |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@client/playwright.config.ts` at line 36, Replace the hardcoded command string
in the Playwright config's command property ("bun --bun next dev") with an npm
script invocation so the config uses the project's single source of truth;
change the value to call the package.json dev script (e.g., "bun run dev" or
"npm run dev" depending on your project) so updates to scripts.dev automatically
apply to Playwright's launch behavior and avoid drift between Playwright's
command and scripts.dev.
This was referenced Apr 29, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
New Features
Chores
Tests