Test failure in migrations tests on OS X

[Julien Phalip]

I'm seeing a test failure on Python 3.3.6 and 3.4.2 (it passes with 2.7.3):

======================================================================
FAIL: test_makemigrations_with_custom_name (migrations.test_commands.MakeMigrationsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/django/tests/migrations/test_commands.py", line 545, in test_makemigrations_with_custom_name
    content = cmd("0002", migration_name_0002, "--empty")
  File "/django/tests/migrations/test_commands.py", line 531, in cmd
    self.assertTrue(os.path.exists(migration_file))
AssertionError: False is not true

----------------------------------------------------------------------

The issue is that the following migration files get created:

$ ls tests/migrations/migrations_21/
0001_my_custom_migration.py  0001_my_initial_migration.py __init__.py

Note that my_custom_migration.py starts with 0001_ whereas it should start with 0002_. I'm unsure why this wasn't detected by the CI builds. Perhaps there's something broken in my environment but I really don't see what that could be.

Again, this works for me in 2.7 but fails in Python 3.

[Claude Paroz]

I'm unable to reproduce the failure (Python 3.4.1+).

[Julien Phalip]

It's odd. Adding the following sleep() statement allows the tests to consistently pass again:

diff --git a/tests/migrations/test_commands.py b/tests/migrations/test_commands.py
index f4e3878..a23f05a 100644
--- a/tests/migrations/test_commands.py
+++ b/tests/migrations/test_commands.py
@@ -519,6 +519,7 @@ class MakeMigrationsTests(MigrationTestBase):
         Makes sure that makemigrations generate a custom migration.
         """
         def cmd(migration_count, migration_name, *args):
+            from time import sleep; sleep(1)
             with override_settings(MIGRATION_MODULES={"migrations": self.migration_pkg}):
                 try:
                     call_command("makemigrations", "migrations", "--verbosity", "0", "--name", migration_name, *args)

So this seems like some sort of race condition. It's unclear to me how that could be happening though...

[Carl Meyer]

Odd. I can't reproduce either.

[Julien Phalip]

There seems to be some conflicts or side-effects between test_makemigrations_migrations_modules_path_not_exist and test_makemigrations_with_custom_name. If I comment out the former, then the latter passes. If I only run the two tests (runtests.py migrations.test_commands.MakeMigrationsTests.test_makemigrations_migrations_modules_path_not_exist migrations.test_commands.MakeMigrationsTests.test_makemigrations_with_custom_name), then I see the failure.

Could you try running those two tests as in the command above?

[Carl Meyer]

Tried running just those two tests, using the command you gave in the last comment; still no failures here :/

[Tim Graham]

I also cannot reproduce.

[Tim Graham]

Reported by Aymeric in #23970 (both he and Julien are on OS X and I think the other people that reported they couldn't reproduce this are on Linux).

[Collin Anderson]

I can reproduce it on OS X. It happens every time.

[Collin Anderson]

​https://github.com/django/django/pull/3924

[Collin Anderson]

Here's a script the reproduces the underlying behavior in python. I haven't nailed down exactly what versions/platforms are affected.

​https://gist.github.com/collinanderson/6675dc9fdc0b84d80a49

[Tim Graham <timograham@…>]

In faf0d66a80e09be3656a337c33a8e70c7fbab7e3:

Fixed #23850 -- Fixed a migrations test failure on Mac OS X & Python 3