fix/update-dockerfile#1596
Merged
Merged
Conversation
Signed-off-by: sahil.kamble@ayanworks.com <sahil.kamble@ayanworks.com>
Signed-off-by: sahil.kamble@ayanworks.com <sahil.kamble@ayanworks.com>
Signed-off-by: sahil.kamble@ayanworks.com <sahil.kamble@ayanworks.com>
📝 WalkthroughWalkthroughMultiple Dockerfiles now run Prisma CLI commands (migrate deploy and sometimes generate) at container startup via a shell-wrapped CMD; small whitespace/EOF edits in Dockerfiles. docker-compose and docker-compose-dev add Changes
Sequence Diagram(s)sequenceDiagram
participant Container
participant Prisma as "libs/prisma-service\n(npx prisma)"
participant DB as Database
participant App as "Node app\n(dist/...)"
Container->>Prisma: cd libs/prisma-service && npx prisma migrate deploy
Prisma->>DB: apply migrations
DB-->>Prisma: OK
Prisma-->>Container: exit
Container->>App: start node dist/.../main.js
App-->>Container: running
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 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}
There was a problem hiding this comment.
Actionable comments posted: 12
🧹 Nitpick comments (1)
Dockerfiles/Dockerfile.geolocation (1)
22-24: Consider removing the boot-timeprisma generate.Line 11 already runs
npx prisma generate, and Prisma documents thatmigrate deploydoes not generate artifacts. Keeping anothernpx prisma generatein Line 26 just adds startup work and appears to be the reasonlibs/andnode_modules/now need to be writable on Lines 22-24. Unless this image intentionally regenerates the client from runtime-only inputs, I’d drop the boot-timegenerate. (docs.prisma.io)♻️ Possible simplification
-CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/geo-location/main.js"] +CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && cd ../.. && node dist/apps/geo-location/main.js"]Also applies to: 26-26
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Dockerfiles/Dockerfile.geolocation` around lines 22 - 24, Remove the boot-time "npx prisma generate" invocation and any runtime generation logic so the Prisma client is only produced at build time (as already run earlier), then revert the image COPYs that force ownership/writable mounts; specifically, delete the runtime `npx prisma generate` call and update the COPY statements that reference "/app/dist/apps/geo-location/", "/app/libs/", and "/app/node_modules" to not require writable ownership (remove the --chown=nextjs:nodejs flags or replace with standard COPY), ensuring the runtime image no longer needs to regenerate the client or writable libs/node_modules.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@Dockerfiles/Dockerfile.agent-service`:
- Line 36: The Dockerfile's CMD currently runs "cd libs/prisma-service && npx
prisma migrate deploy && npx prisma generate && cd ../.. && node
dist/apps/agent-service/main.js", which causes all services to run migrations
concurrently; remove the migrate/generate steps from the CMD so the container
only starts the app (invoke node dist/apps/agent-service/main.js) and instead
add a separate migration job/container that runs "cd libs/prisma-service && npx
prisma migrate deploy" once (e.g., a Kubernetes Job or a docker-compose service
with restart: "no" and proper depends_on for the DB), keeping prisma generate at
build time so the Prisma client is included in node_modules.
In `@Dockerfiles/Dockerfile.api-gateway`:
- Line 26: The Dockerfile's CMD currently runs "npx prisma migrate deploy" in
the api-gateway container (CMD in Dockerfiles/Dockerfile.api-gateway,
libs/prisma-service, npx prisma migrate deploy), which risks migration
race/failure impacting downstream services; remove the migration step from the
api-gateway startup command and instead run migrations from a dedicated
migration runner (e.g., a Kubernetes Job or a separate "migration" container) or
implement a guarded single-run wrapper that uses a distributed lock and retries
before starting node dist/apps/api-gateway/main.js so the api-gateway container
only starts the app and does not perform migrations at boot.
In `@Dockerfiles/Dockerfile.connection`:
- Line 26: The current CMD in Dockerfile.connection runs "prisma migrate deploy"
inside the connection container (see CMD ["sh", "-c", "cd libs/prisma-service &&
npx prisma migrate deploy && npx prisma generate && cd ../.. && node
dist/apps/connection/main.js"]) which races with migrations from other services;
replace this by moving migration logic into a robust entrypoint script that the
connection image runs instead: the script should wait for DB and any
migration-owner services to be ready (retry/connect loop), run "npx prisma
migrate deploy" and "npx prisma generate" only after readiness is confirmed,
then start the app (node dist/apps/connection/main.js); update the Dockerfile to
use that entrypoint and remove the inline migrate command from the CMD so
migrations are serialized and retried reliably for the connection service.
In `@Dockerfiles/Dockerfile.ecosystem`:
- Line 26: The Docker CMD currently runs migrations and generate at container
start (CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy &&
npx prisma generate && cd ../.. && node dist/apps/ecosystem/main.js"]), which
risks concurrent migrate races and redundant runtime generate; remove the "npx
prisma migrate deploy && npx prisma generate" part from the CMD so the container
only runs "node dist/apps/ecosystem/main.js", and instead run "npx prisma
migrate deploy" and "npx prisma generate" in a separate init step (Kubernetes
initContainer, CI/CD job, or startup job) that completes before services start
to ensure migrations run once and generates are done prior to the app process.
In `@Dockerfiles/Dockerfile.geolocation`:
- Line 26: The runtime fails because the Dockerfile runs `pnpm prune --prod`
(removing devDependencies) but the CMD calls `npx prisma ...`; move the "prisma"
package from devDependencies to dependencies in the root package.json so the
Prisma CLI is included after prune, update the lockfile (run pnpm install),
rebuild the image, and verify the container can run `npx prisma migrate deploy
&& npx prisma generate` in the libs/prisma-service context at startup.
In `@Dockerfiles/Dockerfile.ledger`:
- Line 26: The Dockerfile currently runs "npx prisma migrate deploy && npx
prisma generate" in the runtime CMD but earlier runs "pnpm prune --prod", so the
Prisma CLI (declared in devDependencies) will be removed and the CMD will fail;
either (A) move "prisma" from devDependencies to dependencies in the root
package.json so "npx prisma" is available at runtime, or (B) run database
migrations and Prisma codegen during the image build (e.g., in the build stage
for the libs/prisma-service) and remove the Prisma invocations from the CMD so
CMD only runs the app (node dist/apps/ledger/main.js); update the Dockerfile CMD
and/or package.json accordingly and ensure libs/prisma-service artifacts exist
after build.
In `@Dockerfiles/Dockerfile.notification`:
- Line 25: The CMD currently runs via "sh -c" so the shell remains PID 1 and
won't forward SIGTERM to your Node process; update the command that runs
migrations and then starts the app so the final process is exec'd (e.g., prepend
exec before the Node invocation) so the Node binary at
dist/apps/notification/main.js becomes PID 1 and receives shutdown signals; keep
the existing npx prisma migrate deploy and npx prisma generate steps but ensure
the chain ends with exec node dist/apps/notification/main.js (or switch to an
exec form) instead of leaving a non-exec shell.
In `@Dockerfiles/Dockerfile.organization`:
- Line 26: The CMD currently runs concurrent migrations and an unnecessary
generate step: remove "npx prisma migrate deploy" and "npx prisma generate" from
the CMD that lives in Dockerfile (the entry that targets libs/prisma-service and
node dist/apps/organization/main.js) to avoid race conditions and redundant
work; instead change the CMD to just start the app (run node
dist/apps/organization/main.js) and move migrations to a separate startup
mechanism (an init container, a one-off migration job, or a dedicated entrypoint
that acquires a DB lock/leader election and retries) so only one instance runs
"npx prisma migrate deploy" while keeping "prisma generate" out because it
already runs at build time.
In `@Dockerfiles/Dockerfile.user`:
- Line 26: The Dockerfile CMD runs "cd libs/prisma-service && npx prisma migrate
deploy && npx prisma generate && ... node dist/apps/user/main.js", which causes
runtime migration race conditions and an unnecessary prisma generate; change
this so the image does not run migrations/generation on container start — move
prisma migrate deploy and prisma generate to the build/CI stage (or an init
script that runs once with leader election) and have the CMD simply start the
app (node dist/apps/user/main.js) or call a safe startup script that only runs
migrations once with coordination; reference the CMD entry that invokes prisma
migrate deploy and prisma generate in libs/prisma-service to locate and
remove/relocate these runtime steps.
In `@Dockerfiles/Dockerfile.utility`:
- Line 26: The Docker CMD currently runs `prisma migrate deploy` and `prisma
generate` at container start (see CMD invoking "cd libs/prisma-service && npx
prisma migrate deploy && npx prisma generate && ..."), causing migration race
conditions and redundant runtime codegen; move those steps out of the runtime
CMD: run `npx prisma migrate deploy` and `npx prisma generate` during the image
build (or in a controlled startup script that acquires a distributed lock) and
change the CMD to only start the service (e.g., node dist/apps/utility/main.js)
so migrations/codegen are not executed concurrently at container start. Ensure
references to the prisma service directory (libs/prisma-service) and the startup
command (node dist/apps/utility/main.js) are updated accordingly.
In `@Dockerfiles/Dockerfile.x509`:
- Line 26: The CMD in Dockerfile.x509 currently runs "npx prisma migrate deploy"
and "npx prisma generate" at container startup which risks race conditions when
multiple services start; remove both migration and generate steps from the
runtime CMD (leave only the app start: node dist/apps/x509/main.js) and perform
migrations as a separate init step (e.g., a one-off migration container/job that
runs "cd libs/prisma-service && npx prisma migrate deploy" before app containers
start); keep "npx prisma generate" only at build time so the generated client is
baked into node_modules and not executed at runtime.
---
Nitpick comments:
In `@Dockerfiles/Dockerfile.geolocation`:
- Around line 22-24: Remove the boot-time "npx prisma generate" invocation and
any runtime generation logic so the Prisma client is only produced at build time
(as already run earlier), then revert the image COPYs that force
ownership/writable mounts; specifically, delete the runtime `npx prisma
generate` call and update the COPY statements that reference
"/app/dist/apps/geo-location/", "/app/libs/", and "/app/node_modules" to not
require writable ownership (remove the --chown=nextjs:nodejs flags or replace
with standard COPY), ensuring the runtime image no longer needs to regenerate
the client or writable libs/node_modules.
🪄 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: 8d892e59-0913-444d-be5f-a5f26b09e07c
📒 Files selected for processing (17)
Dockerfiles/Dockerfile.agent-serviceDockerfiles/Dockerfile.api-gatewayDockerfiles/Dockerfile.cloud-walletDockerfiles/Dockerfile.connectionDockerfiles/Dockerfile.ecosystemDockerfiles/Dockerfile.geolocationDockerfiles/Dockerfile.issuanceDockerfiles/Dockerfile.ledgerDockerfiles/Dockerfile.notificationDockerfiles/Dockerfile.oid4vc-issuanceDockerfiles/Dockerfile.oid4vc-verificationDockerfiles/Dockerfile.organizationDockerfiles/Dockerfile.userDockerfiles/Dockerfile.utilityDockerfiles/Dockerfile.verificationDockerfiles/Dockerfile.webhookDockerfiles/Dockerfile.x509
| COPY --from=build --chown=nextjs:nodejs /app/node_modules ./node_modules | ||
| USER nextjs | ||
| CMD ["node", "dist/apps/agent-service/main.js"] | ||
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/agent-service/main.js"] No newline at end of file |
There was a problem hiding this comment.
Same migration race condition risk across all service Dockerfiles.
This PR applies the same startup pattern to 16 services. All will attempt prisma migrate deploy simultaneously on startup, risking migration failures, lock contention, and transient errors.
Recommended migration strategy:
- Dedicated migration job: Create a separate migration container/job that runs
prisma migrate deployonce and exits. In Kubernetes, use a Job withinitContainersor Helm hooks. In docker-compose:
services:
migrate:
image: ghcr.io/credebl/api-gateway:latest
command: ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy"]
depends_on:
- postgres # Add your DB service
restart: "no"
api-gateway:
depends_on:
migrate:
condition: service_completed_successfully
# ...- Remove runtime migrate/generate: Simplify all service CMDs to just start the app:
-CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/agent-service/main.js"]
+CMD ["node", "dist/apps/agent-service/main.js"]- Keep build-time generate: The
prisma generateon line 16 is sufficient—the client is included innode_modules.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfiles/Dockerfile.agent-service` at line 36, The Dockerfile's CMD
currently runs "cd libs/prisma-service && npx prisma migrate deploy && npx
prisma generate && cd ../.. && node dist/apps/agent-service/main.js", which
causes all services to run migrations concurrently; remove the migrate/generate
steps from the CMD so the container only starts the app (invoke node
dist/apps/agent-service/main.js) and instead add a separate migration
job/container that runs "cd libs/prisma-service && npx prisma migrate deploy"
once (e.g., a Kubernetes Job or a docker-compose service with restart: "no" and
proper depends_on for the DB), keeping prisma generate at build time so the
Prisma client is included in node_modules.
| COPY --from=build --chown=nextjs:nodejs /app/node_modules ./node_modules | ||
| USER nextjs | ||
| CMD ["node", "dist/apps/api-gateway/main.js"] | ||
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/api-gateway/main.js"] No newline at end of file |
There was a problem hiding this comment.
Same migration race condition risk—critical path service.
api-gateway is a dependency for many downstream services. If migrations fail due to concurrent access or database unavailability, it will cascade failures to dependent services.
Consider making api-gateway the single migration runner (if you must run at startup), or better, use a dedicated migration job.
Suggested fix
-CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/api-gateway/main.js"]
+CMD ["node", "dist/apps/api-gateway/main.js"]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfiles/Dockerfile.api-gateway` at line 26, The Dockerfile's CMD
currently runs "npx prisma migrate deploy" in the api-gateway container (CMD in
Dockerfiles/Dockerfile.api-gateway, libs/prisma-service, npx prisma migrate
deploy), which risks migration race/failure impacting downstream services;
remove the migration step from the api-gateway startup command and instead run
migrations from a dedicated migration runner (e.g., a Kubernetes Job or a
separate "migration" container) or implement a guarded single-run wrapper that
uses a distributed lock and retries before starting node
dist/apps/api-gateway/main.js so the api-gateway container only starts the app
and does not perform migrations at boot.
| COPY --from=build --chown=nextjs:nodejs /app/node_modules ./node_modules | ||
| USER nextjs | ||
| CMD ["node", "dist/apps/connection/main.js"] | ||
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/connection/main.js"] No newline at end of file |
There was a problem hiding this comment.
Same migration race condition risk.
Per docker-compose.yml, connection service depends on nats, api-gateway, utility, and user—but none of these guarantee migrations have completed before this service attempts its own prisma migrate deploy.
Suggested fix
-CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/connection/main.js"]
+CMD ["node", "dist/apps/connection/main.js"]📝 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
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/connection/main.js"] | |
| CMD ["node", "dist/apps/connection/main.js"] |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfiles/Dockerfile.connection` at line 26, The current CMD in
Dockerfile.connection runs "prisma migrate deploy" inside the connection
container (see CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate
deploy && npx prisma generate && cd ../.. && node
dist/apps/connection/main.js"]) which races with migrations from other services;
replace this by moving migration logic into a robust entrypoint script that the
connection image runs instead: the script should wait for DB and any
migration-owner services to be ready (retry/connect loop), run "npx prisma
migrate deploy" and "npx prisma generate" only after readiness is confirmed,
then start the app (node dist/apps/connection/main.js); update the Dockerfile to
use that entrypoint and remove the inline migrate command from the CMD so
migrations are serialized and retried reliably for the connection service.
| COPY --from=build --chown=nextjs:nodejs /app/node_modules ./node_modules | ||
| USER nextjs | ||
| CMD ["node", "dist/apps/ecosystem/main.js"] | ||
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/ecosystem/main.js"] No newline at end of file |
There was a problem hiding this comment.
Same migration race condition risk.
Concurrent prisma migrate deploy and redundant prisma generate at runtime. Consider running migrations as a separate init job before services start.
Suggested fix
-CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/ecosystem/main.js"]
+CMD ["node", "dist/apps/ecosystem/main.js"]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfiles/Dockerfile.ecosystem` at line 26, The Docker CMD currently runs
migrations and generate at container start (CMD ["sh", "-c", "cd
libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd
../.. && node dist/apps/ecosystem/main.js"]), which risks concurrent migrate
races and redundant runtime generate; remove the "npx prisma migrate deploy &&
npx prisma generate" part from the CMD so the container only runs "node
dist/apps/ecosystem/main.js", and instead run "npx prisma migrate deploy" and
"npx prisma generate" in a separate init step (Kubernetes initContainer, CI/CD
job, or startup job) that completes before services start to ensure migrations
run once and generates are done prior to the app process.
| COPY --from=build --chown=nextjs:nodejs /app/node_modules ./node_modules | ||
| USER nextjs | ||
| CMD ["node", "dist/apps/geo-location/main.js"] | ||
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/geo-location/main.js"] No newline at end of file |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Expected: the package manifest used by the runtime image exposes 'prisma' under dependencies, not only devDependencies."
echo
python <<'PY'
import json
from pathlib import Path
for path in Path('.').rglob('package.json'):
if 'node_modules' in path.parts:
continue
data = json.loads(path.read_text())
deps = {
'prisma_dep': data.get('dependencies', {}).get('prisma'),
'prisma_devdep': data.get('devDependencies', {}).get('prisma'),
'prisma_client_dep': data.get('dependencies', {}).get('@prisma/client'),
'prisma_client_devdep': data.get('devDependencies', {}).get('@prisma/client'),
}
deps = {k: v for k, v in deps.items() if v is not None}
if deps:
print(f"== {path} ==")
print(json.dumps(deps, indent=2))
print()
PY
echo "Dockerfile context:"
rg -n -C2 'pnpm prune --prod|npx prisma (migrate deploy|generate)' Dockerfiles/Dockerfile.geolocationRepository: credebl/platform
Length of output: 812
🏁 Script executed:
cat -n Dockerfiles/Dockerfile.geolocationRepository: credebl/platform
Length of output: 1349
Move the prisma package from devDependencies to dependencies in the root package.json.
The Dockerfile builds at line 13 with pnpm prune --prod, which removes all devDependencies from the production node_modules. Line 26 of the runtime stage then attempts to execute npx prisma migrate deploy && npx prisma generate, but the prisma CLI will not be available since it currently resides only in devDependencies. The container will fail during startup. Moving prisma to dependencies ensures the CLI is retained after the production prune and available at runtime.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfiles/Dockerfile.geolocation` at line 26, The runtime fails because the
Dockerfile runs `pnpm prune --prod` (removing devDependencies) but the CMD calls
`npx prisma ...`; move the "prisma" package from devDependencies to dependencies
in the root package.json so the Prisma CLI is included after prune, update the
lockfile (run pnpm install), rebuild the image, and verify the container can run
`npx prisma migrate deploy && npx prisma generate` in the libs/prisma-service
context at startup.
| COPY --from=build --chown=nextjs:nodejs /app/node_modules ./node_modules | ||
| USER nextjs | ||
| CMD ["node", "dist/apps/organization/main.js"] | ||
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/organization/main.js"] No newline at end of file |
There was a problem hiding this comment.
Same migration race condition risk as other Dockerfiles.
This CMD has the same issues: concurrent prisma migrate deploy across services and redundant prisma generate (already run at build time on line 11). See the detailed analysis in Dockerfile.x509 review.
Suggested fix
-CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/organization/main.js"]
+CMD ["node", "dist/apps/organization/main.js"]📝 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
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/organization/main.js"] | |
| CMD ["node", "dist/apps/organization/main.js"] |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfiles/Dockerfile.organization` at line 26, The CMD currently runs
concurrent migrations and an unnecessary generate step: remove "npx prisma
migrate deploy" and "npx prisma generate" from the CMD that lives in Dockerfile
(the entry that targets libs/prisma-service and node
dist/apps/organization/main.js) to avoid race conditions and redundant work;
instead change the CMD to just start the app (run node
dist/apps/organization/main.js) and move migrations to a separate startup
mechanism (an init container, a one-off migration job, or a dedicated entrypoint
that acquires a DB lock/leader election and retries) so only one instance runs
"npx prisma migrate deploy" while keeping "prisma generate" out because it
already runs at build time.
| COPY --from=build --chown=nextjs:nodejs /app/node_modules ./node_modules | ||
| USER nextjs | ||
| CMD ["node", "dist/apps/user/main.js"] | ||
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/user/main.js"] No newline at end of file |
There was a problem hiding this comment.
Same migration race condition risk.
Concurrent prisma migrate deploy and redundant prisma generate at runtime.
Suggested fix
-CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/user/main.js"]
+CMD ["node", "dist/apps/user/main.js"]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfiles/Dockerfile.user` at line 26, The Dockerfile CMD runs "cd
libs/prisma-service && npx prisma migrate deploy && npx prisma generate && ...
node dist/apps/user/main.js", which causes runtime migration race conditions and
an unnecessary prisma generate; change this so the image does not run
migrations/generation on container start — move prisma migrate deploy and prisma
generate to the build/CI stage (or an init script that runs once with leader
election) and have the CMD simply start the app (node dist/apps/user/main.js) or
call a safe startup script that only runs migrations once with coordination;
reference the CMD entry that invokes prisma migrate deploy and prisma generate
in libs/prisma-service to locate and remove/relocate these runtime steps.
| COPY --from=build --chown=nextjs:nodejs /app/node_modules ./node_modules | ||
| USER nextjs | ||
| CMD ["node", "dist/apps/utility/main.js"] | ||
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/utility/main.js"] No newline at end of file |
There was a problem hiding this comment.
Same migration race condition risk.
Concurrent prisma migrate deploy and redundant prisma generate at runtime.
Suggested fix
-CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/utility/main.js"]
+CMD ["node", "dist/apps/utility/main.js"]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfiles/Dockerfile.utility` at line 26, The Docker CMD currently runs
`prisma migrate deploy` and `prisma generate` at container start (see CMD
invoking "cd libs/prisma-service && npx prisma migrate deploy && npx prisma
generate && ..."), causing migration race conditions and redundant runtime
codegen; move those steps out of the runtime CMD: run `npx prisma migrate
deploy` and `npx prisma generate` during the image build (or in a controlled
startup script that acquires a distributed lock) and change the CMD to only
start the service (e.g., node dist/apps/utility/main.js) so migrations/codegen
are not executed concurrently at container start. Ensure references to the
prisma service directory (libs/prisma-service) and the startup command (node
dist/apps/utility/main.js) are updated accordingly.
| COPY --from=build --chown=nextjs:nodejs /app/node_modules ./node_modules | ||
| USER nextjs | ||
| CMD ["node", "dist/apps/verification/main.js"] | ||
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/verification/main.js"] No newline at end of file |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Startup migration commands:"
rg -n -C1 'npx prisma migrate deploy' \
Dockerfiles/Dockerfile.verification \
Dockerfiles/Dockerfile.user \
Dockerfiles/Dockerfile.api-gateway
echo
echo "verification service compose block:"
rg -n -A12 -B2 '^verification:' docker-compose-dev.ymlRepository: credebl/platform
Length of output: 811
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Find docker-compose files
echo "=== Docker-compose files in repo ==="
fd -e yml -e yaml | grep -i 'docker-compose'
echo
echo "=== Content of docker-compose-dev.yml (verification service section) ==="
# Search for verification service
rg -n -A15 'verification:' docker-compose-dev.yml 2>/dev/null || echo "Pattern not found with 'verification:' - trying alternative pattern"
echo
echo "=== Alternative search in docker-compose-dev.yml ==="
rg -n 'verification' docker-compose-dev.yml 2>/dev/null || echo "No matches found"Repository: credebl/platform
Length of output: 877
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== All Dockerfiles running prisma migrations ==="
rg -l 'prisma migrate deploy' Dockerfiles/
echo
echo "=== Check for any init/migration containers in docker-compose ==="
rg -n 'image.*migration|migration.*image|init' docker-compose-dev.yml || echo "No migration/init containers found"
echo
echo "=== Verify depends_on uses plain service names (no conditions) ==="
rg -n 'condition:' docker-compose-dev.yml || echo "No health check conditions found"Repository: credebl/platform
Length of output: 934
Move schema migrations to a dedicated init container instead of running from every service.
All 17 service containers (api-gateway, user, verification, connection, issuance, ledger, organization, agent-service, agent-provisioning, notification, ecosystem, geolocation, cloud-wallet, oid4vc-issuance, oid4vc-verification, utility, webhook, x509) independently run npx prisma migrate deploy on startup. The docker-compose depends_on only controls container start order—not task completion—so a multi-service startup can trigger 17 concurrent migrations against the same database. Create a dedicated migration init container, run the migration once there before other services start, and remove migration commands from all service Dockerfiles.
| COPY --from=build --chown=nextjs:nodejs /app/node_modules ./node_modules | ||
| USER nextjs | ||
| CMD ["node", "dist/apps/x509/main.js"] No newline at end of file | ||
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/x509/main.js"] |
There was a problem hiding this comment.
Race condition risk: Multiple services running migrations simultaneously.
Based on docker-compose.yml (lines 1-75), there are no health checks or database service dependencies defined. When multiple services start concurrently, they will all execute prisma migrate deploy simultaneously, which can cause:
- Migration conflicts: Concurrent DDL operations may fail or produce inconsistent state
- Database locks: Prisma uses an advisory lock (
_prisma_migrationstable), but simultaneous attempts can still cause transient failures and container restarts
Additionally, npx prisma generate is redundant here—it already runs at build time (line 11), and the generated client is included in the copied node_modules.
Recommendation: Run migrations as a separate init job (e.g., Kubernetes Job, docker-compose run --rm command, or a dedicated migration container) that completes before application containers start. Keep only prisma generate at build time.
Suggested fix for startup command
-CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/x509/main.js"]
+CMD ["node", "dist/apps/x509/main.js"]Run migrations separately before deployment:
# Example: one-time migration command
docker run --rm --env-file .env <image> sh -c "cd libs/prisma-service && npx prisma migrate deploy"📝 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
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma generate && cd ../.. && node dist/apps/x509/main.js"] | |
| CMD ["node", "dist/apps/x509/main.js"] |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfiles/Dockerfile.x509` at line 26, The CMD in Dockerfile.x509 currently
runs "npx prisma migrate deploy" and "npx prisma generate" at container startup
which risks race conditions when multiple services start; remove both migration
and generate steps from the runtime CMD (leave only the app start: node
dist/apps/x509/main.js) and perform migrations as a separate init step (e.g., a
one-off migration container/job that runs "cd libs/prisma-service && npx prisma
migrate deploy" before app containers start); keep "npx prisma generate" only at
build time so the generated client is baked into node_modules and not executed
at runtime.
Signed-off-by: sahil.kamble@ayanworks.com <sahil.kamble@ayanworks.com>
Signed-off-by: sahil.kamble@ayanworks.com <sahil.kamble@ayanworks.com>
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docker-compose-dev.yml`:
- Line 132: The docker-compose-dev.yml override uses "user: root", which
reintroduces root privileges; update the service entries that set "user: root"
to run as the non-root application user instead (e.g., match the Dockerfile's
USER nextjs or use a UID:GID variable), and ensure the corresponding Dockerfile
or image creates and switches to that user (refer to the "user: root" lines and
the Dockerfile's "USER nextjs" declaration); if host-volume permission requires
it, prefer setting user: "${UID}:${GID}" via environment substitution and
document the needed UID/GID rather than using root.
- Around line 196-231: The four new service entries (ecosystem, oid4vc-issuance,
oid4vc-verification, x509) lack the user: root setting, causing permission
errors when their Dockerfiles switch to USER nextjs and run npx prisma migrate
deploy; update each service block to include user: root (consistent with
agent-provisioning and agent-service) so database migrations run as root during
container startup before the non-root user is used.
In `@docker-compose.yml`:
- Line 121: The docker-compose entry overrides the Dockerfile's non-root user by
setting "user: root"; remove or avoid using "user: root" in the service
definition and instead implement one of the safer alternatives: run Prisma
migrations as a separate init job/one-shot container before starting the main
service (so the main service runs as the Dockerfile's "nextjs" user), or change
the Dockerfile to chown the required runtime/migration directories to the
"nextjs" user so the service can write without root, or if you must run a
migration step as root, confine that to a dedicated migration container and
ensure the main "nextjs" service drops privileges (does not include "user:
root") after migrations complete.
In `@Dockerfiles/Dockerfile.ecosystem`:
- Around line 25-26: The Dockerfile sets USER nextjs but the CMD runs "npx
prisma migrate deploy", causing permission errors because migrations require
root; fix by either (A) making the ecosystem service run migrations as root by
adding user: root to the ecosystem service in docker-compose-dev.yml so the
existing CMD succeeds, or (B) remove migrations from the container start and run
them separately (e.g., run npx prisma migrate deploy in a dedicated init
container or CI step) and leave USER nextjs in the Dockerfile; target the
Dockerfile USER nextjs and the CMD "npx prisma migrate deploy" as the symbols to
change, or update the ecosystem service in docker-compose-dev.yml to include
user: root.
🪄 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: d4795066-de45-4342-b374-c2da7d0d93bd
📒 Files selected for processing (19)
Dockerfiles/Dockerfile.agent-serviceDockerfiles/Dockerfile.api-gatewayDockerfiles/Dockerfile.cloud-walletDockerfiles/Dockerfile.connectionDockerfiles/Dockerfile.ecosystemDockerfiles/Dockerfile.geolocationDockerfiles/Dockerfile.issuanceDockerfiles/Dockerfile.ledgerDockerfiles/Dockerfile.notificationDockerfiles/Dockerfile.oid4vc-issuanceDockerfiles/Dockerfile.oid4vc-verificationDockerfiles/Dockerfile.organizationDockerfiles/Dockerfile.userDockerfiles/Dockerfile.utilityDockerfiles/Dockerfile.verificationDockerfiles/Dockerfile.webhookDockerfiles/Dockerfile.x509docker-compose-dev.ymldocker-compose.yml
✅ Files skipped from review due to trivial changes (1)
- Dockerfiles/Dockerfile.verification
🚧 Files skipped from review as they are similar to previous changes (14)
- Dockerfiles/Dockerfile.oid4vc-issuance
- Dockerfiles/Dockerfile.api-gateway
- Dockerfiles/Dockerfile.organization
- Dockerfiles/Dockerfile.geolocation
- Dockerfiles/Dockerfile.utility
- Dockerfiles/Dockerfile.connection
- Dockerfiles/Dockerfile.notification
- Dockerfiles/Dockerfile.cloud-wallet
- Dockerfiles/Dockerfile.oid4vc-verification
- Dockerfiles/Dockerfile.ledger
- Dockerfiles/Dockerfile.x509
- Dockerfiles/Dockerfile.issuance
- Dockerfiles/Dockerfile.webhook
- Dockerfiles/Dockerfile.agent-service
| - ./.env | ||
| environment: | ||
| - ROOT_PATH=$PWD/apps/agent-provisioning/AFJ/agent-config | ||
| user: root |
There was a problem hiding this comment.
Running containers as root introduces security risks.
Same concern as docker-compose.yml: overriding USER nextjs to run as root negates non-root security benefits. Consider the architectural suggestions mentioned in the docker-compose.yml review to minimize root usage.
Also applies to: 155-155
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docker-compose-dev.yml` at line 132, The docker-compose-dev.yml override uses
"user: root", which reintroduces root privileges; update the service entries
that set "user: root" to run as the non-root application user instead (e.g.,
match the Dockerfile's USER nextjs or use a UID:GID variable), and ensure the
corresponding Dockerfile or image creates and switches to that user (refer to
the "user: root" lines and the Dockerfile's "USER nextjs" declaration); if
host-volume permission requires it, prefer setting user: "${UID}:${GID}" via
environment substitution and document the needed UID/GID rather than using root.
Comment on lines
+196
to
+231
| ecosystem: | ||
| depends_on: | ||
| - nats | ||
| - api-gateway | ||
| build: | ||
| context: ./ # Adjust the context path as needed | ||
| dockerfile: Dockerfiles/Dockerfile.ecosystem | ||
| env_file: | ||
| - ./.env | ||
| oid4vc-issuance: | ||
| depends_on: | ||
| - nats | ||
| - api-gateway | ||
| build: | ||
| context: ./ # Adjust the context path as needed | ||
| dockerfile: Dockerfiles/Dockerfile.oid4vc-issuance | ||
| env_file: | ||
| - ./.env | ||
| oid4vc-verification: | ||
| depends_on: | ||
| - nats | ||
| - api-gateway | ||
| build: | ||
| context: ./ # Adjust the context path as needed | ||
| dockerfile: Dockerfiles/Dockerfile.oid4vc-verification | ||
| env_file: | ||
| - ./.env | ||
| x509: | ||
| depends_on: | ||
| - nats | ||
| - api-gateway | ||
| build: | ||
| context: ./ # Adjust the context path as needed | ||
| dockerfile: Dockerfiles/Dockerfile.x509 | ||
| env_file: | ||
| - ./.env |
There was a problem hiding this comment.
Missing user: root for new services will cause startup failures.
The new services (ecosystem, oid4vc-issuance, oid4vc-verification, x509) are missing user: root, but their Dockerfiles:
- Declare
USER nextjs(uid 1001) in the final stage - Run
npx prisma migrate deployin CMD
This inconsistency with agent-provisioning and agent-service (which have user: root) will cause these four services to fail at startup with permission errors when attempting database migrations.
🔧 Proposed fix to add user: root
ecosystem:
depends_on:
- nats
- api-gateway
build:
context: ./ # Adjust the context path as needed
dockerfile: Dockerfiles/Dockerfile.ecosystem
env_file:
- ./.env
+ user: root
oid4vc-issuance:
depends_on:
- nats
- api-gateway
build:
context: ./ # Adjust the context path as needed
dockerfile: Dockerfiles/Dockerfile.oid4vc-issuance
env_file:
- ./.env
+ user: root
oid4vc-verification:
depends_on:
- nats
- api-gateway
build:
context: ./ # Adjust the context path as needed
dockerfile: Dockerfiles/Dockerfile.oid4vc-verification
env_file:
- ./.env
+ user: root
x509:
depends_on:
- nats
- api-gateway
build:
context: ./ # Adjust the context path as needed
dockerfile: Dockerfiles/Dockerfile.x509
env_file:
- ./.env
+ user: root📝 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
| ecosystem: | |
| depends_on: | |
| - nats | |
| - api-gateway | |
| build: | |
| context: ./ # Adjust the context path as needed | |
| dockerfile: Dockerfiles/Dockerfile.ecosystem | |
| env_file: | |
| - ./.env | |
| oid4vc-issuance: | |
| depends_on: | |
| - nats | |
| - api-gateway | |
| build: | |
| context: ./ # Adjust the context path as needed | |
| dockerfile: Dockerfiles/Dockerfile.oid4vc-issuance | |
| env_file: | |
| - ./.env | |
| oid4vc-verification: | |
| depends_on: | |
| - nats | |
| - api-gateway | |
| build: | |
| context: ./ # Adjust the context path as needed | |
| dockerfile: Dockerfiles/Dockerfile.oid4vc-verification | |
| env_file: | |
| - ./.env | |
| x509: | |
| depends_on: | |
| - nats | |
| - api-gateway | |
| build: | |
| context: ./ # Adjust the context path as needed | |
| dockerfile: Dockerfiles/Dockerfile.x509 | |
| env_file: | |
| - ./.env | |
| ecosystem: | |
| depends_on: | |
| - nats | |
| - api-gateway | |
| build: | |
| context: ./ # Adjust the context path as needed | |
| dockerfile: Dockerfiles/Dockerfile.ecosystem | |
| env_file: | |
| - ./.env | |
| user: root | |
| oid4vc-issuance: | |
| depends_on: | |
| - nats | |
| - api-gateway | |
| build: | |
| context: ./ # Adjust the context path as needed | |
| dockerfile: Dockerfiles/Dockerfile.oid4vc-issuance | |
| env_file: | |
| - ./.env | |
| user: root | |
| oid4vc-verification: | |
| depends_on: | |
| - nats | |
| - api-gateway | |
| build: | |
| context: ./ # Adjust the context path as needed | |
| dockerfile: Dockerfiles/Dockerfile.oid4vc-verification | |
| env_file: | |
| - ./.env | |
| user: root | |
| x509: | |
| depends_on: | |
| - nats | |
| - api-gateway | |
| build: | |
| context: ./ # Adjust the context path as needed | |
| dockerfile: Dockerfiles/Dockerfile.x509 | |
| env_file: | |
| - ./.env | |
| user: root |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docker-compose-dev.yml` around lines 196 - 231, The four new service entries
(ecosystem, oid4vc-issuance, oid4vc-verification, x509) lack the user: root
setting, causing permission errors when their Dockerfiles switch to USER nextjs
and run npx prisma migrate deploy; update each service block to include user:
root (consistent with agent-provisioning and agent-service) so database
migrations run as root during container startup before the non-root user is
used.
| - ./.env | ||
| environment: | ||
| - ROOT_PATH=$PWD/apps/agent-provisioning/AFJ/agent-config | ||
| user: root |
There was a problem hiding this comment.
Running containers as root introduces security risks.
Overriding the Dockerfile's USER nextjs directive to run as root negates the security benefits of the non-root user. While this may be necessary for Prisma migrations and volume writes, consider:
- Running migrations as a separate init container or one-time job before services start
- Adjusting file/directory ownership in the Dockerfile so the
nextjsuser can write to required paths - If root is unavoidable for migrations, dropping privileges after migration completes
Also applies to: 142-142
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docker-compose.yml` at line 121, The docker-compose entry overrides the
Dockerfile's non-root user by setting "user: root"; remove or avoid using "user:
root" in the service definition and instead implement one of the safer
alternatives: run Prisma migrations as a separate init job/one-shot container
before starting the main service (so the main service runs as the Dockerfile's
"nextjs" user), or change the Dockerfile to chown the required runtime/migration
directories to the "nextjs" user so the service can write without root, or if
you must run a migration step as root, confine that to a dedicated migration
container and ensure the main "nextjs" service drops privileges (does not
include "user: root") after migrations complete.
Comment on lines
25
to
+26
| USER nextjs | ||
| CMD ["node", "dist/apps/ecosystem/main.js"] | ||
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && cd ../.. && node dist/apps/ecosystem/main.js"] No newline at end of file |
There was a problem hiding this comment.
Permission mismatch: non-root user cannot run migrations.
The USER nextjs directive (Line 25) conflicts with the CMD running npx prisma migrate deploy (Line 26). The ecosystem service in docker-compose-dev.yml does not specify user: root, unlike agent-provisioning and agent-service. This will cause permission failures at container startup.
Either add user: root to the ecosystem service in docker-compose-dev.yml, or restructure to run migrations separately before starting the service.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfiles/Dockerfile.ecosystem` around lines 25 - 26, The Dockerfile sets
USER nextjs but the CMD runs "npx prisma migrate deploy", causing permission
errors because migrations require root; fix by either (A) making the ecosystem
service run migrations as root by adding user: root to the ecosystem service in
docker-compose-dev.yml so the existing CMD succeeds, or (B) remove migrations
from the container start and run them separately (e.g., run npx prisma migrate
deploy in a dedicated init container or CI step) and leave USER nextjs in the
Dockerfile; target the Dockerfile USER nextjs and the CMD "npx prisma migrate
deploy" as the symbols to change, or update the ecosystem service in
docker-compose-dev.yml to include user: root.
Signed-off-by: sahil.kamble@ayanworks.com <sahil.kamble@ayanworks.com>
|
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
docker-compose.yml (1)
121-121:⚠️ Potential issue | 🟠 MajorRunning these services as root remains a security risk.
Line 121 and Line 142 still override container user to
root, which expands blast radius (especially with Docker socket mounts). This was already raised in earlier review feedback and remains unresolved.Also applies to: 142-142
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docker-compose.yml` at line 121, The compose file sets two services to run as root via the "user: root" entries (seen at the two occurrences) which is a security risk; change each service to use a non-root numeric UID/GID or a dedicated unprivileged user created in the image (e.g., add a non-root user in the Dockerfile and set user: "<uid>:<gid>" or remove the user override so the container runs as the image's non-root user), and ensure any mounted volumes/permissions are adjusted accordingly so the non-root account can access needed files; update both "user: root" occurrences to this non-root user approach.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@Dockerfiles/Dockerfile.seed`:
- Line 16: Remove the migration command from the seed container CMD in
Dockerfile.seed (the current CMD invoking "npx prisma migrate deploy && npx
prisma db seed") and instead create a dedicated one-shot init service in
docker-compose that runs "npx prisma migrate deploy" (followed by "npx prisma db
seed" if seeding is desired) so migrations run once; update all application
services (api-gateway, user, utility, organization, webhook, verification, x509,
issuance, notification, ledger, ecosystem, connection, geolocation,
oid4vc-issuance, oid4vc-verification, cloud-wallet, agent-provisioning,
agent-service, seed) to use depends_on on that new init service to ensure
serialized migrations before they start. Ensure the new init service uses the
same DB config as the app (same env/volumes/networks) and is defined as a
one-shot command (not restart: always) so it runs once and exits successfully
before dependent containers start.
---
Duplicate comments:
In `@docker-compose.yml`:
- Line 121: The compose file sets two services to run as root via the "user:
root" entries (seen at the two occurrences) which is a security risk; change
each service to use a non-root numeric UID/GID or a dedicated unprivileged user
created in the image (e.g., add a non-root user in the Dockerfile and set user:
"<uid>:<gid>" or remove the user override so the container runs as the image's
non-root user), and ensure any mounted volumes/permissions are adjusted
accordingly so the non-root account can access needed files; update both "user:
root" occurrences to this non-root user approach.
🪄 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: 08951369-77c3-4868-9c16-6a3f7aee80c3
📒 Files selected for processing (7)
Dockerfiles/Dockerfile.seedapps/agent-provisioning/AFJ/scripts/docker_start_agent.shapps/agent-provisioning/AFJ/scripts/fargate.shapps/agent-provisioning/AFJ/scripts/on_premises_agent.shapps/agent-provisioning/AFJ/scripts/start_agent.shapps/agent-provisioning/AFJ/scripts/start_agent_ecs.shdocker-compose.yml
✅ Files skipped from review due to trivial changes (3)
- apps/agent-provisioning/AFJ/scripts/start_agent_ecs.sh
- apps/agent-provisioning/AFJ/scripts/fargate.sh
- apps/agent-provisioning/AFJ/scripts/on_premises_agent.sh
| && chown -R nextjs:nodejs /app | ||
| USER nextjs | ||
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma db seed"] No newline at end of file | ||
| CMD ["sh", "-c", "cd libs/prisma-service && npx prisma migrate deploy && npx prisma db seed"] No newline at end of file |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Find all startup commands that run prisma migrate deploy =="
rg -n --no-heading 'prisma migrate deploy' Dockerfiles docker-compose.yml docker-compose-dev.yml
echo
echo "== Inspect seed service block for startup ordering constraints =="
rg -n -A20 -B2 '^ seed:' docker-compose.yml
echo
echo "== Inspect api-gateway block for migration overlap context =="
rg -n -A20 -B2 '^ api-gateway:' docker-compose.ymlRepository: credebl/platform
Length of output: 4835
Serialize Prisma migrations with a dedicated init service instead of distributing across all containers.
Line 16 adds prisma migrate deploy to the seed service, but this compounds a systemic issue: nearly 20 services (api-gateway, user, utility, organization, webhook, verification, x509, issuance, notification, ledger, ecosystem, connection, geolocation, oid4vc-issuance, oid4vc-verification, cloud-wallet, agent-provisioning, agent-service, and seed) all run migrations independently at startup. The docker-compose.yml seed service has no depends_on constraints, so migrations execute in parallel across containers with no coordination. This creates race conditions and lock contention, causing intermittent startup failures.
Move migrations to a separate initialization service that runs once before other containers start, then have all services depend on it via depends_on.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfiles/Dockerfile.seed` at line 16, Remove the migration command from
the seed container CMD in Dockerfile.seed (the current CMD invoking "npx prisma
migrate deploy && npx prisma db seed") and instead create a dedicated one-shot
init service in docker-compose that runs "npx prisma migrate deploy" (followed
by "npx prisma db seed" if seeding is desired) so migrations run once; update
all application services (api-gateway, user, utility, organization, webhook,
verification, x509, issuance, notification, ledger, ecosystem, connection,
geolocation, oid4vc-issuance, oid4vc-verification, cloud-wallet,
agent-provisioning, agent-service, seed) to use depends_on on that new init
service to ensure serialized migrations before they start. Ensure the new init
service uses the same DB config as the app (same env/volumes/networks) and is
defined as a one-shot command (not restart: always) so it runs once and exits
successfully before dependent containers start.
RinkalBhojani
approved these changes
Apr 1, 2026
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
2 participants
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.
What ?
Summary by CodeRabbit
Chores
New Features
Chores