Skip to content

fix: explicitly set machineConfig to null when task machine is removed #3056

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
deepshekhardas wants to merge 1 commit into from
Closed

fix: explicitly set machineConfig to null when task machine is removed #3056

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion apps/webapp/app/v3/services/createBackgroundWorker.server.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -276,7 +276,7 @@ async function createWorkerTask(
exportName: task.exportName,
retryConfig: task.retry,
queueConfig: task.queue,
Comment on lines 277 to 278
Copy link

@devin-ai-integration devin-ai-integration bot Feb 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚩 Inconsistent undefined-to-null handling for sibling Json? fields

The fix applies ?? null only to machineConfig, but the same create() call passes two other Json? fields — retryConfig: task.retry (line 277) and queueConfig: task.queue (line 278) — that are also optional on TaskResource (packages/core/src/v3/schemas/resources.ts:10-11) and map to Json? columns in the Prisma schema (internal-packages/database/prisma/schema.prisma:559-561). If the rationale for this fix is that Prisma's create() silently skips undefined for Json? columns, the same issue would apply to retryConfig and queueConfig. However, in practice removing retry/queue config may be far less common or impactful than removing machine config, which is likely why only machineConfig was addressed. Still, for consistency and defense-in-depth, the same ?? null pattern should arguably be applied to the other two fields.

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

machineConfig: task.machine,
machineConfig: task.machine ?? null,
Copy link

@devin-ai-integration devin-ai-integration bot Feb 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚩 Prisma create() should already set NULL for omitted undefined fields

The PR description states that "Prisma's create() silently skips undefined fields for Json? columns rather than setting them to NULL." However, for a Prisma create() call, omitting a field (by passing undefined) causes Prisma to exclude it from the generated INSERT statement, which means the database column default is used. For machineConfig Json? (internal-packages/database/prisma/schema.prisma:561), there is no explicit default, so the PostgreSQL column default is NULL. This means the original code machineConfig: task.machine should have already resulted in NULL being stored when task.machine is undefined. The fix with ?? null is still a good defensive practice (making intent explicit), but the root cause of the reported bug (#2796) may lie elsewhere — perhaps in how contentHash is computed (if removing machine config didn't change the hash, the early return at line 63 would skip creating a new worker entirely, preserving the old machineConfig).

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

triggerSource: task.triggerSource === "schedule" ? "SCHEDULED" : "STANDARD",
fileId: tasksToBackgroundFiles?.get(task.id) ?? null,
maxDurationInSeconds: task.maxDuration ? clampMaxDuration(task.maxDuration) : null,
Expand Down