This is related to the issue mentioned on this post, but specifically pertaining to a problem I discovered with the Fauna Dashboard resetting the value on a GraphQL type that is configured as a Float.
It is somewhat pointed out in this solution (namely, in this part):
Now, if I create a Document directly with JS or the Dashboard and wrap the value in
ToDoublethen we explicitly tell Fauna to store the value as a double-precision floating point number. When GraphQL fetches the data it expects a Float and receives a float.
However, there is no clarification on what happens when a document already exists and you are simply trying to update a portion of it via the Fauna Dashboard.
In my scenario, I had some data that I originally created via a GraphQL mutation. As explained in the aforementioned solution, documents created through GraphQL are serialized properly and I can confirm that this was my experience as well. Today, I had a situation where I needed to update a small portion of this document. The Fauna Dashboard is a convenient way to do this as it is relatively easy to click through and change things in the UI as opposed to writing out a GraphQL mutation. After making the change, however, I ran into the same error from the linked post.
Unfortunately, the appearance of value for the field with the Float type always appears as an Int from the UI in cases where there is no decimal point (regardless of how it was created). Without the context of the solution from the linked post, I was unaware that I had inadvertently set this value to an Int when I assumed I was just updating the value of a single, different field.
Perhaps this post is slightly redundant, but I wanted to add it for 2 reasons:
- To provide better visibility for others that may run into this particular situation (i.e., original document created via GraphQL mutation then updated via the UI which results in errors from your GraphQL application)
- To inquire as to whether the internal ticket mentioned in the linked post (I can’t link to it as a new user, but it is the reply immediately after the linked solution) would cover a change for the UI to prevent this behavior in the future (and, if not, whether an additional ticket to do so would be reasonable)
Finally, I want to conclude by reiterating that updating the document via a GraphQL mutation (or using the ToDouble method as discussed in the linked solution) should probably suffice as a workaround. I actually ended up just deleting and recreating the document entirely, but I understand that this is not likely to be feasible in most cases.