Misleading questions on "Quiz 5 | Build a Python application with Redis"

[simple harness]

Hello!
I believe the questions on quiz 5 are a bit misleading. the pipeline object that is returned from the redis.pipelines has by default transaction = true which means that the commands will run atomically (if i understand correctly).
So the first question What's the difference between Redis pipelines and transactions? Choose one answer..
where the correct answer is Transactions execute atomically; pipelines don't. I believe is a bit problematic since by default, pipelines use the transaction variable.
Same in question 3: Suppose you execute a Redis transaction with three commands. What happens when the second command fails with an error inside the transaction? Choose one answer:
Since by default it uses the transaction variable, none of the commands will run.

Attaching screenshot for visualisation

Thank you for your responses

[hazy isle]

I believe that, unlike relational databases where transactions follow an “all or nothing” principle, in Redis ,even when using MULTI/EXEC , commands are executed sequentially and in isolation, but without automatic rollback.
This means that if one command inside the transaction fails during execution, the others will still run normally, and Redis will simply return the corresponding errors in the result.
In other words, transactions in non-relational databases tend to have non-fully-atomic behavior, prioritizing performance over full consistency.
A similar example is MongoDB, which also allows batch operations to continue even when individual operations fail.

However, if the error happens before the EXEC command, such as a syntax error or anything that invalidates the queued commands inside the MULTI block, Redis will abort the entire transaction, and none of the commands will be executed. This is the only case where it truly cancels everything. I believe the atomicity in Redis is mostly related to the blocking of its single execution thread during the MULTI/EXEC phase, no other client can interleave commands while the transaction is being processed ,ensuring isolation and sequential execution.
In other words, this atomicity is at the level of sequential and isolated execution, not rollback

[simple harness]

You are talking about the 3rd question if I understand correctly
i asked chatgpt ans it said this

💡 What Redis actually does

Redis queues all commands during MULTI, but doesn’t run them immediately.
When you call EXEC, it executes them sequentially.

If a command fails during queuing (before EXEC), the entire transaction is aborted — Redis returns an error and nothing runs.

But if a command fails during execution (after EXEC), then:

✅ All other commands still run.
❌ The failing command just returns an error for its result.

So based on what you said and what Chat says, I understand that lets say we try to increment a string this will produce an error for said command but not a rollback since other commands that are inside the MULTI will run sequentially.
I can't think of a case where the entire transaction will be aborted, but nevertheless thank you for your response 😁

As for the first question I still believe it is misleading.
I believe these tutorials are a bit hard to understand since you jump to a full on project with design patterns such as DAO that have a level of complexity themselves. Maybe a smaller project as an intermediate level would be much more easy to digest, since the previous tutorials just give you a basic understanding of the types of redis and some funtions that you can use. At least for me who I just graduated it seems a bit too much to understand.

[simple harness]

I am not sure again about my understanding of how transactions work after reading a bit more about it.
since transcation = True adds everything under a MULTI/EXEC block this means that if due to network error or false operation (increment a string) all will fail.
with transaction = Off this wont happen. If network error all the previous commands will run while for a false operation also everything after this operation will run since they are not insie a MULTI/EXEC command.
What remains is what happens if there is a race condition:
say while we run the increment of a number another user deletes this number (when we are inside the multi/exec). Is this prevented somehow (LUA scripts)?

[hazy isle]

If a network error happens before EXEC is received by the server, none of the commands will run (because they’re still in the client buffer)
If the network error happens after EXEC, the transaction may still be executed ,the client just won’t see the result.
If a command like INCR on a string key fails, the other commands inside MULTI/EXEC will still execute. The failed command will just return an error in the results array

transaction=True = all commands are queued and then executed atomically in one batch.However, Redis does not perform rollback
transaction=False = commands are sent in bulk but executed one by one ,there’s no isolation or atomicity.If a network issue occurs halfway through, some commands may have executed and others not.
Redis doesn’t provide full optimistic or pessimistic locking automatically.
If one client deletes a key while another is preparing to increment it inside a MULTI/EXEC, the operation will fail at EXEC time because the watched key changed ,but only if you explicitly use WATCH
Without WATCH, the deletion and increment can overlap, and Redis just executes in the order they arrive.
In short:

MULTI/EXEC = atomic execution (no rollback)

WATCH = optimistic concurrency control

Lua scripts = atomic + isolated execution (best for complex operations)

When you try to increment a string or run an invalid command inside MULTI/EXEC, Redis will only return an error for that specific command and still execute the rest sequentially , no rollback involved.
The only case where the entire transaction is aborted is when an error occurs before EXEC for example, a syntax error or a command that fails during the queuing phase. In that case, Redis returns EXECABORT and skips everything.
And yes, I totally agree with your point about the tutorials. Jumping from basic Redis commands straight into a full project that uses design patterns like DAO can be overwhelming.