Ember cannot call writableChainWatchers after the object is destroyed

I've had my share of obscure error messages in Ember tests with no useful stack trace or any other information to figure out the underlying cause, but this case takes the prize for being the most obscure of them all.

I have this Ember app where tests are failing in a very bizarre way:

$ ember test -m "Acceptance | main report"                                                                                                                                                                1 ↵
cleaning up...
Built project successfully. Stored in "/home/username/work/my-project/frontend/tmp/core_object-tests_dist-HinFNKHW.tmp".
ok 1 PhantomJS 2.1 - Acceptance | main report: visiting main home
not ok 2 PhantomJS 2.1 - Acceptance | main report: it changes structure
    ---
        actual: >
            false
        expected: >
            true
        stack: >
            exception@http://localhost:7357/!/assets/test-support.js:7199:49
            adapterDispatch@http://localhost:7357/!/assets/js/vendor.js:54101:22
            dispatchError@http://localhost:7357/!/assets/js/vendor.js:32467:23
            onerrorDefault@http://localhost:7357/!/assets/js/vendor.js:46036:32
            trigger@http://localhost:7357/!/assets/js/vendor.js:73035:19
            http://localhost:7357/!/assets/js/vendor.js:73935:28
            invoke@http://localhost:7357/!/assets/js/vendor.js:15192:18
            flush@http://localhost:7357/!/assets/js/vendor.js:15260:15
            flush@http://localhost:7357/!/assets/js/vendor.js:15384:20
            end@http://localhost:7357/!/assets/js/vendor.js:15454:28
            run@http://localhost:7357/!/assets/js/vendor.js:15577:19
            http://localhost:7357/!/assets/js/vendor.js:15873:29
        message: >
            Error: Assertion Failed: Cannot call writableChainWatchers after the object is destroyed.
        Log: |
    ...

1..2
# tests 2
# pass  1
# skip  0
# fail  1
Not all tests passed.
Error: Not all tests passed.
    at EventEmitter.App.getExitCode (/home/username/work/my-project/frontend/node_modules/testem/lib/app.js:434:15)
    at EventEmitter.App.exit (/home/username/work/my-project/frontend/node_modules/testem/lib/app.js:189:23)
    at /home/username/work/my-project/frontend/node_modules/testem/lib/app.js:103:14
    at tryCatcher (/home/username/work/my-project/frontend/node_modules/testem/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/home/username/work/my-project/frontend/node_modules/testem/node_modules/bluebird/js/release/promise.js:510:31)
    at Promise._settlePromise (/home/username/work/my-project/frontend/node_modules/testem/node_modules/bluebird/js/release/promise.js:567:18)
    at Promise._settlePromise0 (/home/username/work/my-project/frontend/node_modules/testem/node_modules/bluebird/js/release/promise.js:612:10)
    at Promise._settlePromises (/home/username/work/my-project/frontend/node_modules/testem/node_modules/bluebird/js/release/promise.js:691:18)
    at Async._drainQueue (/home/username/work/my-project/frontend/node_modules/testem/node_modules/bluebird/js/release/async.js:133:16)
    at Async._drainQueues (/home/username/work/my-project/frontend/node_modules/testem/node_modules/bluebird/js/release/async.js:143:10)
    at Immediate.Async.drainQueues [as _onImmediate] (/home/username/work/my-project/frontend/node_modules/testem/node_modules/bluebird/js/release/async.js:17:14)
    at processImmediate [as _immediateCallback] (timers.js:383:17)

Note the error message:

Cannot call writableChainWatchers after the object is destroyed.

My first question is, how can I figure out what's the cause of this weird error, when the stack trace I get is anything but helpful. Not only is it unhelpful to get these insane line numbers of the built vendor.js, but also nothing in the stack trace comes from my app itself. So no line number that could help me here.

Also, this error situation does not occur when running the app in dev or production environment. It's just happening in the test environment.

And finally, and perhaps more important: I realized that the cause of the error has something to do with state leaking from one test to another. In that test file you can see there are two tests. The first one passes, but the second one fails. When I commented the first one, to focus in the only failing test, it turns out it does not fail. When I swap the order of these two tests in the file, then the one that was failing, that used to be second in order, now that it is the first one it does not fail. And conversely, the one that was passing when it was first, it's now failing when it comes last.