fix: Improve payload typings for Tasker handlers #14988
Conversation
|
@anikdhabal is attempting to deploy a commit to the cal Team on Vercel. A member of the Team first needs to authorize it. |
github-actions
bot
added
High priority
|
Thank you for following the naming conventions! 🙏 Feel free to join our discord and post your PR link. |
Graphite Automations"Add community label" took an action on this PR • (05/12/24)1 label was added to this PR based on Keith Williams's automation. "Add consumer team as reviewer" took an action on this PR • (05/12/24)1 reviewer was added to this PR based on Keith Williams's automation. |
📦 Next.js Bundle Analysis for @calcom/webThis analysis was generated by the Next.js Bundle Analysis action. 🤖 Three Pages Changed SizeThe following pages changed size from the code in this PR compared to its base branch:
DetailsOnly the gzipped size is provided here based on an expert tip. First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If Any third party scripts you have added directly to your app using the The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/- <0.01%" it means that there was a change in bundle size, but it is a trivial enough amount that it can be ignored. |
| export async function sendEmail(payload: string): Promise<void> { | ||
| try { | ||
| const parsedPayload = sendEmailPayloadSchema.parse(JSON.parse(payload)); | ||
| const parsedPayloadObj: SendEmailPayload = JSON.parse(payload); |
There was a problem hiding this comment.
So now if the string payload we pass to this function doesn't match the SendEmailPayload type that we have inferred from the zod schema defined earlier, we would get a TypeError exception, correct?
@anikdhabal Please help me out in understanding this aspect of the changes
There was a problem hiding this comment.
Payload is saved in DB as string always. So no. This won't prevent getting an error on compile time. We also need to keep the runtime protection as well.
There was a problem hiding this comment.
Got it @zomars. Will have a further look
There was a problem hiding this comment.
Thank you for your contribution 🙏 Left some comments about the approach of this PR.
The idea overall is close to what we want but in the current state is not giving us the compile time protection while removing the runtime one. Which is not an acceptable trade off.
I would recommend coming up with an approach that checks both compile time and runtime.
Thanks @zomars for your review. I will fix that shortly. |
| export async function sendEmail(payload: string): Promise<void> { | ||
| try { | ||
| const parsedPayload = sendEmailPayloadSchema.parse(JSON.parse(payload)); | ||
| const parsedPayload: SendEmailPayload = sendEmailPayloadSchema.parse(JSON.parse(payload)); |
There was a problem hiding this comment.
Hey @anikdhabal as far as I know, parsedPayload already has the correct type inference. These typing should be added to the packages/features/tasker/tasker.ts typings in order to keep the task creation type safe. Not in here. Will close the PR for now. 🙏
What does this PR do?
Mandatory Tasks (DO NOT REMOVE)
How should this be tested?
Checklist