Hi Klemen

We recently changed atomic() to mark when it is created by the test runner
for this ticket: https://code.djangoproject.com/ticket/33161 . This was for
special case logic around the 'durable' flag to atomic().

Perhaps the newly added tracking can also be used for the check in
select_for_update(), and perhaps other things that require an atomic()
(i.e. they check connection.in_atomic_block). You could investigate if a
patch is feasible.

FWIW I always recommend enabling ATOMIC_REQUESTS and ensuring transactions
are used by default in other code paths such as background tasks.

Thanks,

Adam

On Wed, 17 Nov 2021 at 21:02, Klemen Štrajhar <klemen.straj...@gmail.com>
wrote:

> Hi!
> I noticed dangerous behaviour with testing and usage of *select_for_update
> *in transactions.
> This "feature" crashed some parts of production in our company.
> The "feature" I am talking about, is that test runner wraps all tests in a
> transaction. If you use *select_for_update* you have to wrap it in a
> transaction.atomic(). That is quite obvious as django raises an error if
> query is not in a transaction.
> This is what happened at our company:
>
>    1. One code block was wrapped in transaction atomic where
>    select_for_update was used. The code was tested in a django test.
>    2. transaction.atomic context manager was accidentally removed. The
>    test still passed as test runner wraps test in it's own transaction.
>    3. Code was happily deployed
>    4. On production server there was no more transaction wrapper and
>    exception was raised at select_for_update
>    5. ...
>    6. Hotfix galore
>
> Is there any option to separate the transaction wrapper for testing and
> normal code execution? I am not familiar with internals of test runner
> etc., but would gladly take a look.
> What are your opinions about this?
> - Klemen
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/be5bd163-5915-4890-b225-78094c773eb8n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/be5bd163-5915-4890-b225-78094c773eb8n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM31-kaB6CZVZ2Hk-0A62wAF7-95ifEKYnY%2BDXY4DfkmWw%40mail.gmail.com.
  • sel... Klemen Štrajhar
    • ... 'Adam Johnson' via Django developers (Contributions to Django itself)
      • ... Klemen Štrajhar
      • ... Florian Apolloner
        • ... Aymeric Augustin
          • ... Florian Apolloner
            • ... Carlton Gibson

Reply via email to