internal-packages/run-engine/src/engine/systems/checkpointSystem.ts (1)

117-133: Transaction leakage: using this.$.prisma inside a tx-scoped method bypasses the provided transaction

Both createCheckpoint() and continueRunExecution() derive a local prisma = tx ?? this.$.prisma but then call this.$.prisma.taskRun.update(...). This escapes the transaction when tx is provided, risking inconsistent state and race conditions.

Apply these diffs to use the tx-scoped client:

-      const run = await this.$.prisma.taskRun.update({
+      const run = await prisma.taskRun.update({
         where: {
           id: runId,
         },
         data: {
           status: "WAITING_TO_RESUME",
         },
         include: {
           runtimeEnvironment: {
             include: {
               project: true,
               organization: true,
             },
           },
         },
       });

-      const run = await this.$.prisma.taskRun.update({
+      const run = await prisma.taskRun.update({
         where: {
           id: runId,
         },
         data: {
           status: "EXECUTING",
         },
         select: {
           id: true,
           status: true,
           attemptNumber: true,
           organizationId: true,
           runtimeEnvironmentId: true,
           projectId: true,
           updatedAt: true,
           createdAt: true,
         },
       });

Also applies to: 295-312

internal-packages/run-engine/src/engine/systems/checkpointSystem.ts (2)

65-68: Trim logged payload to avoid large/PII-heavy logs

Logging the whole snapshot can be verbose and may include sensitive/large metadata. Consider logging only identifiers and status.

Apply this diff:

-        this.$.logger.info("Tried to createCheckpoint on an invalid snapshot", {
-          snapshot,
-          snapshotId,
-        });
+        this.$.logger.info("Tried to createCheckpoint on an invalid snapshot", {
+          snapshotId,
+          latestSnapshotId: snapshot.id,
+          executionStatus: snapshot.executionStatus,
+        });

---

315-318: Incorrect log message references createCheckpoint in continueRunExecution

The message says "Run not found for createCheckpoint" but this is inside continueRunExecution(), which can mislead ops triage.

Apply this diff:

-        this.$.logger.error("Run not found for createCheckpoint", {
+        this.$.logger.error("Run not found for continueRunExecution", {
           snapshot,
         });

internal-packages/run-engine/src/engine/systems/dequeueSystem.ts (2)

136-144: Prefer structured logging over string interpolation

Switching to structured objects improves queryability in log aggregation (filter by runId/snapshotId/status) and avoids embedded newlines.

Apply this diff:

-                if (isExecuting(snapshot.executionStatus)) {
-                  this.$.logger.error(
-                    `RunEngine.dequeueFromWorkerQueue(): Run is not in a valid state to be dequeued: ${runId}\n ${snapshot.id}:${snapshot.executionStatus}`
-                  );
-                } else {
-                  this.$.logger.warn(
-                    `RunEngine.dequeueFromWorkerQueue(): Run is in an expected not valid state to be dequeued: ${runId}\n ${snapshot.id}:${snapshot.executionStatus}`
-                  );
-                }
+                if (isExecuting(snapshot.executionStatus)) {
+                  this.$.logger.error(
+                    "RunEngine.dequeueFromWorkerQueue(): Run is not in a valid state to be dequeued",
+                    {
+                      runId,
+                      snapshotId: snapshot.id,
+                      executionStatus: snapshot.executionStatus,
+                    }
+                  );
+                } else {
+                  this.$.logger.warn(
+                    "RunEngine.dequeueFromWorkerQueue(): Run is in an expected not-valid state to be dequeued",
+                    {
+                      runId,
+                      snapshotId: snapshot.id,
+                      executionStatus: snapshot.executionStatus,
+                    }
+                  );
+                }

---

88-96: Nit: log message still says dequeueFromMasterQueue

This method is dequeueFromWorkerQueue; keeping log identifiers consistent helps debugging.

Apply this diff:

-                  this.$.logger.error(
-                    "RunEngine.dequeueFromMasterQueue(): Run is already PENDING_EXECUTING, removing from queue",
+                  this.$.logger.error(
+                    "RunEngine.dequeueFromWorkerQueue(): Run is already PENDING_EXECUTING, removing from queue",
                     {
                       runId,
                       orgId,
                     }
                   );

apps/webapp/app/v3/services/alerts/deliverAlert.server.ts (2)

955-959: Include Slack retryAfter in logs for rate limiting

Adding retryAfter makes SRE decisions easier and could inform backoff strategies.

Apply this diff:

-        logger.warn("[DeliverAlert] Slack rate limited", {
-          error,
-          message,
-        });
+        logger.warn("[DeliverAlert] Slack rate limited", {
+          error,
+          message,
+          retryAfter: error.retryAfter,
+        });

Optionally, consider re-enqueuing the alert with a delay of retryAfter seconds to avoid immediate retries.

I can draft a small helper to nack/re-enqueue with delay using alertsWorker if you'd like.

---

981-985: Platform error downgraded to warn — consider classifying more non-retriable codes

You already special-case invalid_blocks and account_inactive. Other common non-retriables (e.g., channel_not_found, is_archived, not_in_channel, token_revoked, invalid_auth, not_authed) could also skip retries to further reduce noise.

Apply this diff to extend skip logic:

       if (isWebAPIPlatformError(error)) {
         logger.warn("[DeliverAlert] Slack platform error", {
           error,
           message,
         });

         if (error.data.error === "invalid_blocks") {
           logger.error("[DeliverAlert] Slack invalid blocks", {
             error,
           });

           throw new SkipRetryError("Slack invalid blocks");
         }

-        if (error.data.error === "account_inactive") {
+        const NON_RETRIABLE_PLATFORM_ERROR_CODES = new Set([
+          "account_inactive",
+          "channel_not_found",
+          "is_archived",
+          "not_in_channel",
+          "token_revoked",
+          "invalid_auth",
+          "not_authed",
+        ]);
+
+        if (NON_RETRIABLE_PLATFORM_ERROR_CODES.has(error.data.error)) {
           logger.info("[DeliverAlert] Slack account inactive, skipping retry", {
             error,
             message,
           });

-          throw new SkipRetryError("Slack account inactive");
+          throw new SkipRetryError(`Slack non-retriable platform error: ${error.data.error}`);
         }

If you'd prefer, I can scope this to a smaller subset.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.