bug: [v4] retrying after schema fails
Provide environment information
System: OS: Linux 5.15 Ubuntu 20.04.6 LTS (Focal Fossa) CPU: (12) x64 AMD Ryzen 5 5600X 6-Core Processor Memory: 4.84 GB / 15.59 GB Container: Yes Shell: 3.7.1 - /usr/bin/fish Binaries: Node: 18.20.8 - ~/.local/share/nvm/v18.20.8/bin/node npm: 10.8.2 - ~/.local/share/nvm/v18.20.8/bin/npm pnpm: 8.6.3 - ~/.local/share/pnpm/pnpm
Describe the bug
According to the docs, when the schema fails it should not retry, but it does.
This is unnecessarily increasing the run time and cost.
Reproduction repo
added screenshot below.
To reproduce
convert-or-decrypt-link.ts
import { AbortTaskRunError, logger, schemaTask, tags } from '@trigger.dev/sdk';
import type { CnLinkSerial } from 'cn-links';
import { CnLink } from 'cn-links';
import { z } from 'zod';
import { decryptLink } from './decrypt-link';
export const convertOrDecryptLink = schemaTask({
id: 'convert-or-decrypt-link',
schema: z.object({
link: z.string().url(),
}),
// Set an optional maxDuration to prevent tasks from running indefinitely
maxDuration: 30,
run: async (payload: { link: string }): Promise<CnLinkSerial> => {
const url = new URL(payload.link);
// do something. It triggers another task here and/or adds tags, so I know for sure that it fails during the initial schema.
},
});
Tested in production and local development.
Additional information
There is an error message for an invalid schema (taken from elsewhere)
So it looks like this may have been caused by the child task, which has stricter schema rules and uses refine.
export const decryptLink = schemaTask({
id: 'decrypt-link',
schema: z.object({
link: z
.string()
.url()
.refine((val) => HostnameSchema.safeParse(new URL(val).hostname).success),
}),
This would match the error, it's 100% in the decrypt-link function and not convert-or-decrypt-link, because the URL schema is actually not illegal, HostnameSchema is causing it to fail.
But then it should still fail in the child task, not the parent task, and it should still not retry. The screenshot above shows no indication the the child task was even called, so I think this might be a problem where a child task is called with a schema.
Hey @cachho thanks a lot for these great, very detailed issues you've been creating - please keep them coming! We're currently incredibly busy with v4 reliability improvements but we'll get around to all of them in due time, promise.
This one is definitely an annoying bug and we need to fix it.