🐛 Bug Report: int attributes in appwrite accepts numbers as String about appwrite HOT 10 OPEN

Ok, I have reproduced this bug. It's a bit nuanced. There is no error from Appwrite because it turns your string into an int but returns a string in the create event response. If you then fetch the documents it will return the new entry with the correct type.

My thoughts are that Appwrite should either:

• Throw an error when you pass anything that is not an int
• Or it should return the create response with the attribute as an int after it parses it to int type in the background

from appwrite.

Ok, I have reproduced this bug. It's a bit nuanced. There is no error from Appwrite because it turns your string into an int but returns a string in the create event response. If you then fetch the documents it will return the new entry with the correct type.

My thoughts are that Appwrite should either:

• Throw an error when you pass anything that is not an int
• Or it should return the create response with the attribute as an int after it parses it to int type in the background

Yes,

Because the "Create event" returns the data before parsing it, it will cause issues if I expect an int from request.body in the function and get a string instead.

I think the most effective solution is the first one you suggested:

• Throw an error when you pass anything that is not an int

from appwrite.

@stnguyen90 This is intentional, it would just add unnecessary friction to throw an error if the string is a valid integer. The event should definitely fire with with an int though.

from appwrite.

It seems you have passed the amount a string value so it inferred it as a string, did you explicitly set the amount as int in appwrite? or set the type of amount to be an int type somewhere else in the code?

from appwrite.

It seems you have passed the amount a string value so it inferred it as a string, did you explicitly set the amount as int in appwrite? or set the type of amount to be an int type somewhere else in the code?

The AMOUNT attribute is an int in appwrite, it should never accept Numbers as strings, ever.

But from what I see it accepts numbers as Strings then maybe it got parsed in the process in appwrite before it reaches the database but__ the function event caught it before it got parsed, and this is the issue with that, if a programming error happens in the front end and the programmer pass the value as a string, appwrite should throw an error,

If I'm expecting to get an int value from the function event but got String instead that will cause problems.

Why parse the value and then write it to the database when you can make it only accept int simply?

from appwrite.

It seems you have passed the amount a string value so it inferred it as a string, did you explicitly set the amount as int in appwrite? or set the type of amount to be an int type somewhere else in the code?

try the Reproduction steps...

from appwrite.

Throw an error when you pass anything that is not an int

Yes, I agree we should throw an error if the incorrect type is passed.

Would either of you be interested in working on this?

from appwrite.

I'd love to give it a shot

from appwrite.

@stnguyen90 This is intentional, it would just add unnecessary friction to throw an error if the string is a valid integer. The event should definitely fire with with an int though.

The it should return the create response with the attribute as an int after it parses it to int type in the background..

from appwrite.

This is intentional, it would just add unnecessary friction to throw an error if the string is a valid integer. The event should definitely fire with with an int though.

@abnegate, so where and how would be the best place to convert the attribute such that we don't miss anything and we handle all attribute? The Structure validation should only be for validation and shouldn't mutate the data, right? Would we need to update encode()?

from appwrite.