Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #1478 - Project files are not being flushed to disk after being written #1479

Merged
merged 6 commits into from
Nov 17, 2017

Conversation

jturner-22
Copy link
Contributor

@jturner-22 jturner-22 commented Nov 7, 2017

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Proposed changes

Fixes #1478.

The proposed fix calls stream.write() rather than stream.end() to write the file's contents. Then it calls fs.fsync() and finally stream.end() to close the file.

Related changes due to timing differences when running tests

On my test system and Travis CI, this affected some timings and revealed a few race conditions in the existing unit tests for nodes.

  • The first was the Flows startFlows() function being incorrectly stubbed away in "test/red/runtime/nodes/index_spec.js". The wrong object was used in the stub, causing the startFlows() function to still be called, but there was no corresponding call to stopFlows().
    • I don't know if Travis CI would have caught this or not, but I saw it on two different desktops and it was very consistent.
  • The second was the Exec node. A test would pass if stderr only emitted one string, but it can sometimes emit two, as it's a stream. This failed twice on Travis CI for Node 4.
    • I would also see it fail about 25% on my desktop with Node 6. I'd also see these failures without any of my changes here. Race conditions in Node are fun.

I'd rather not include these timing fixes with this PR, but it was the only way I could get all the tests to reliably pass on both my systems and Travis CI.

Checklist

  • I have read the contribution guidelines
  • For non-bugfix PRs, I have discussed this change on the mailing list/slack team.
  • I have run grunt to verify the unit tests pass
  • I have added suitable unit tests to cover the new/changed functionality

The startFlows() function wasn't really being stubbed, so it was still being called. But there was no corresponding call to stopFlows().

In later tests, the check in Flows.init() was throwing the "Cannot init without a stop" error.
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.08%) to 86.148% when pulling 4f71d78 on jturner-22:master into 2b9aa94 on node-red:master.

1 similar comment
@coveralls
Copy link

coveralls commented Nov 7, 2017

Coverage Status

Coverage decreased (-0.08%) to 86.148% when pulling 4f71d78 on jturner-22:master into 2b9aa94 on node-red:master.

@coveralls
Copy link

coveralls commented Nov 7, 2017

Coverage Status

Coverage decreased (-0.07%) to 86.162% when pulling ea78023 on jturner-22:master into 2b9aa94 on node-red:master.

@coveralls
Copy link

coveralls commented Nov 7, 2017

Coverage Status

Coverage increased (+0.006%) to 86.234% when pulling 5dc654e on jturner-22:master into 2b9aa94 on node-red:master.

The startFlows() function wasn't really being stubbed, so it was still being called. But there was no corresponding call to stopFlows().

In later tests, the check in Flows.init() was throwing the "Cannot init without a stop" error.
Occasionally, the error text on stderr will come in more than one piece. The test only worked correctly if a single message was received.
@coveralls
Copy link

coveralls commented Nov 8, 2017

Coverage Status

Coverage decreased (-0.07%) to 86.162% when pulling f6f1a60 on jturner-22:master into 2b9aa94 on node-red:master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Project files are not being flushed to disk after being written
3 participants