How to safely increment counters? (tutorial)

[aiddun]

Hi,

I was working my way through the tutorial and ended with the code below for the starter voting app. I'm unfamiliar with the how/where Blitz handles mutations/data fetching, but is this technically a race condition for incrementing votes below?

If a client has a value of question.choice.votes stored locally from its initial rendering, isn't there a chance that another client could increment the server vote count from its local value, such that that if our client submits a mutation to increment the server vote count to 1 + (our now old) local value, it won't be correct.

Psudocode:
Client A: Get clientA.votes = 2
Client B: Get clientB.votes = 2
Client B: Mutate server.votes = (clientB.votes + 1 ) = (2 + 1) = 3
Client A: Mutate server.votes = (clientA.votes + 1 ) = (2 + 1) = 3
Ideally, server.votes should equal 4, when in actuality it equals 3

Does Blitz avoid this? Where is votes stored/handleVote called (server/client)? If this is a race condition, would a way to resolve it be to make a custom mutation?

Thanks!

Code (from tutorial):

  export const Question = () => {
  const router = useRouter()
  const questionId = useParam("questionId", "number")
  const [question, {refetch}] = useQuery(getQuestion, {where: {id: questionId}})
  const [deleteQuestionMutation] = useMutation(deleteQuestion)
  const [updateChoiceMutation] = useMutation(updateChoice)

  const handleVote = async (id, votes) => {
    try {
      const updated = await updateChoiceMutation({
        where: { id },
        data: { votes: votes + 1 },
      })
      refetch()
      alert("Success!" + JSON.stringify(updated))
    } catch (error) {
      alert("Error creating question " + JSON.stringify(error, null, 2))
    }
  }

  return (
    <div>
      <h1>Question {question.text}</h1>

      <ul>
        {question.choices.map((choice) => (
          <li key={choice.id}>
            {choice.text} - {choice.votes} votes
            <button onClick={() => handleVote(choice.id, choice.votes)}>Vote</button>
          </li>
        ))}
      </ul>

     ...

[aiddun]

If this is a data race, I found Prisma added support for atomics (deep in their docs), which should do the trick
https://www.prisma.io/docs/reference/api-reference/prisma-client-reference#atomic-number-operations

[Skn0tt]

Yes, this snippet has race conditions. It's prone to a lost update:

A and B load questions at the same time, receiving the same number of votes 11.
Now both call updateChoiceMutation with votes + 1, updating the database to 12.
While there should have been a 13 in the database, one of the updates has been lost.

The issue wouldn't be as big if the result of useQuery was always up-to-date - but it isn't. It's refreshed every 30secs or so (at least by default, i think), but it's not real-time in any way. And even if it was (e.g. using websockets), the issue would not disappear - what about two people voting in the exact same millisecond, when none of the clients has had a chance to update?

In short, you should use atomic operations for these kinds of things.

[aiddun]

Thanks for the informative answer!

[flybayer]

Fyi, I've fixed this in the tutorial update I did today :) (I'm using the atomic number operations)

[aiddun]

Wow, thanks!

[flybayer]

This will be in the new website launch in 8 hours or so