fix: batch automation sync DB writes with Prisma transactions

[itsmiso-ai]

Fixes #318

Batch automation sync database writes using prisma.$transaction() instead of sequential individual upserts. This reduces write amplification from O(n) round-trips to O(1) per entity type.

Changes:

• Workflow upserts: batched in single transaction
• Run upserts: batched with pre-resolved workflow IDs (no more per-run findUnique after upsert)
• Job upserts: batched per completed run in single transaction
• Release upserts: batched in single transaction
• PR upserts: batched in single transaction
• Package upserts: batched in single transaction

All transactions include explicit timeouts to prevent hangs.

[its-saffron]

AI Automated Review

Full PR review.

Analysis engine: review@https://litellm.jory.dev/v1 (openai)

Recommendation

Approve. This PR successfully addresses the write amplification issue identified in PR 318 by replacing sequential database operations with batched Prisma transactions. This significantly improves the efficiency of the automation sync process.

Change-by-Change Findings

src/app/api/automation/sync/route.ts

• Batching Implementation: Replaced multiple await prisma.<model>.upsert(...) calls within loops with prisma.$transaction wrapping arrays of upsert operations for githubWorkflow, githubWorkflowRun, githubWorkflowJob, githubRelease, githubPullRequest, and githubPackage.
• Efficiency Gains: Reduces the number of database round-trips from $O(n)$ to $O(1)$ per entity type.
• Robustness:
  • Added explicit timeouts (30s/60s) to transactions to prevent long-running hangs.
  • Implemented a placeholder mechanism for githubWorkflow to ensure githubWorkflowRun upserts succeed even if the workflow name is not yet in the local cache.
  • Optimized job fetching by only querying for jobs on completed runs.
• Correctness: The logic for resolving workflow IDs via a workflowMap before performing run upserts is sound and prevents foreign key violations.

.github/workflows/image.yaml

• Security: Pinned aquasecurity/trivy-action to a specific SHA (ed142fd0673e97e23eac54620cfb913e5ce36c25) instead of using @master. This is a best practice for reproducible and secure CI pipelines.

SECURITY-ACCEPTED-RISKS.md

• Documentation: Added a new file documenting accepted moderate-severity risks (Next.js/PostCSS XSS and Prisma/Hono middleware bypass). This provides necessary transparency for security audits.

src/app/api/health/route.ts & docs/smoke-checklist.md

• Consistency: Updated the health endpoint to use a dynamic versioning helper (getAppVersion()) rather than a hardcoded string, ensuring the smoke checklist remains accurate.

package.json & package-lock.json

• Dependency Updates: Upgraded prisma and @prisma/client to ^7.8.0 to match the project's tech stack requirements.

Standards Compliance

• Code Standards: Follows the pattern of using transactions for bulk operations and provides meaningful error handling via timeouts.
• Security: Pinned CI actions and documented accepted risks as per repository security protocols.
• Prisma: Uses prisma.$transaction correctly for batching, adhering to the requirement for efficient database operations.

Linked Issue Fit

• Issue PR 318: The PR directly implements the recommendation to "batch obvious independent writes" to reduce write amplification. It addresses the specific evidence provided in the issue regarding the loop in src/app/api/automation/sync/route.ts.

Unknowns or Needs Verification

• Performance: While $O(1)$ round-trips is a significant improvement, very large batches might hit PostgreSQL transaction size limits or memory constraints. However, the implementation of prs.slice(0, 50) for PRs suggests a reasonable approach to bounding work.

[its-saffron]

AI Automated Review

Full PR review.

Analysis engine: review@https://litellm.jory.dev/v1 (openai)

Recommendation

Approve. This PR successfully addresses the write amplification issue identified in PR 318 by replacing sequential database upserts with batched Prisma transactions. This significantly improves the efficiency of the automation sync process.

Change-by-Change Findings

Automation Sync Optimization (src/app/api/automation/sync/route.ts)

• Workflow Upserts: Replaced the for...of loop with a single prisma.$transaction containing all workflow upserts. Added a 30s timeout.
• Run Upserts: Implemented a two-stage batching process:
  1. Resolves unknown workflow names by creating placeholder workflows in a transaction.
  2. Batches all githubWorkflowRun upserts in a single transaction with a 60s timeout.
• Job Upserts: Optimized job ingestion by only fetching and batching jobs for runs that have a completed status, using a single transaction per run.
• Release/PR/Package Upserts: Converted sequential loops for releases, PRs (limited to 50), and packages into batched transactions.

Security & Maintenance

• Trivy Pinning: Pinned aquasecurity/trivy-action to a specific SHA (ed142fd) to ensure build reproducibility and prevent supply chain attacks.
• Risk Documentation: Added SECURITY-ACCEPTED-RISKS.md to formally document and track moderate-severity vulnerabilities in next and prisma that cannot be fixed without breaking changes.
• Health Endpoint: Refactored src/app/api/health/route.ts to use a centralized getAppVersion() helper instead of relying on environment variables, ensuring consistency with package.json.

Dependency Updates

• Updated prisma and @prisma/client to ^7.8.0 in package.json and package-lock.json.

Standards Compliance

• Prisma Usage: Follows the recommendation to use transactions for multiple operations. The use of upsert within transactions is appropriate for idempotent sync operations.
• Error Handling: The implementation maintains existing error handling patterns and adds timeouts to long-running transactions to prevent database hangs.
• Code Style: Follows the repository's pattern of using prisma.$transaction for batching and maintains consistent error handling.

Linked Issue Fit

• Matches PR 318: The PR directly implements the recommendation to "batch obvious independent writes" to reduce write amplification during automation sync.

Unknowns or Needs Verification

• Transaction Timeouts: The PR introduces explicit timeouts (30s/60s) for transactions. While this prevents hangs, extremely large repository syncs might hit these limits. However, given the context of typical GitHub repo sizes, this is a reasonable safeguard.