A Null Priority Bug Between UI, Database, and Zod

In a recent incident while working on the FocusYar application, I discovered a bug related to editing tasks without a priority. I created a task with just a title, which resulted in the database storing a priority value of null. When I subsequently opened the edit form and left the priority field empty, I encountered an error message stating: "There is nothing task."

The root cause of this issue stemmed from the way the priority value was being handled across different layers of the application. In my Zod schema, I was checking for undefined values, but the actual value coming from the database was null. I initially attempted to resolve the issue by changing the condition in my Zod schema to check for null, but this did not solve the problem.

Upon further investigation, I traced the complete data flow within the application, from the user interface all the way to the server action. I discovered that the same field was also present in my edit schema. By modifying the check in the edit schema to verify for null values instead of undefined, the bug was successfully resolved.

This experience taught me an important lesson about debugging optional fields. When encountering issues with fields that can be null, undefined, or have empty strings, it is crucial to verify the actual value at every layer of the application. These three distinct values are not interchangeable, and a bug may not be confined to a single layer of the application. It could be the result of how the value flows through various components such as the user interface, database, Zod schema, and server actions.