Opened 10 years ago

Closed 9 years ago

#23850 closed Bug (fixed)

Test failure in migrations tests on OS X

Reported by: Julien Phalip Owned by: nobody
Component: Migrations Version: dev
Severity: Normal Keywords:
Cc: info+coding@…, cmawebsite@… Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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/", line 545, in test_makemigrations_with_custom_name
    content = cmd("0002", migration_name_0002, "--empty")
  File "/django/tests/migrations/", line 531, in cmd
AssertionError: False is not true


The issue is that the following migration files get created:

$ ls tests/migrations/migrations_21/

Note that 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.

Change History (13)

comment:1 by Claude Paroz, 10 years ago

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

comment:2 by Julien Phalip, 10 years ago

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

diff --git a/tests/migrations/ b/tests/migrations/
index f4e3878..a23f05a 100644
--- a/tests/migrations/
+++ b/tests/migrations/
@@ -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}):
                     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...

comment:3 by Markus Holtermann, 10 years ago

Cc: info+coding@… added

comment:4 by Carl Meyer, 10 years ago

Odd. I can't reproduce either.

comment:5 by Julien Phalip, 10 years ago

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 ( 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?

comment:6 by Carl Meyer, 10 years ago

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

comment:7 by Tim Graham, 10 years ago

Resolution: worksforme
Status: newclosed

I also cannot reproduce.

comment:8 by Tim Graham, 10 years ago

Resolution: worksforme
Status: closednew
Triage Stage: UnreviewedAccepted

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).

comment:9 by Collin Anderson, 9 years ago

Cc: cmawebsite@… added
Summary: Test failure in migrations testsTest failure in migrations tests on OS X

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

comment:11 by Collin Anderson, 9 years ago

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

comment:12 by Tim Graham, 9 years ago

Triage Stage: AcceptedReady for checkin

comment:13 by Tim Graham <timograham@…>, 9 years ago

Resolution: fixed
Status: newclosed

In faf0d66a80e09be3656a337c33a8e70c7fbab7e3:

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

Note: See TracTickets for help on using tickets.
Back to Top