Closed vnenkpet closed 7 years ago
@@ Coverage Diff @@
## master #12 +/- ##
==========================================
+ Coverage 93.9% 94.11% +0.21%
==========================================
Files 1 1
Lines 82 85 +3
Branches 5 6 +1
==========================================
+ Hits 77 80 +3
Misses 5 5
Impacted Files | Coverage Δ | |
---|---|---|
index.js | 94.11% <91.11%> (+0.21%) |
:white_check_mark: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 1160e5c...9edccab. Read the comment docs.
@vnenkpet Did this solve the issue?
As stated in a comment in the first reply to http://stackoverflow.com/questions/12906694/fs-createwritestream-does-not-immediately-create-file the WritableStream returned from fs.createWriteStream already waits for the "open" event before writing to the file.
@christensson It did solve the issue. We didn't have any problems with this since then... Thanks for merging!
I've been running into a problem where in about 1 of 150 requests failed with uncaught ENOENT exception.
Following suggestion from this http://stackoverflow.com/questions/12906694/fs-createwritestream-does-not-immediately-create-file I tried adding a piece of code and now it seems that the code is alwyas handled properly... I tried running 1000 tests several times and no problem occured.
However note I am not 100% sure it actually solved this and that it was not just a lucky coincidence.
I've also made some adjustments to the code that ESLint and IDE were complaining about (missing semicolons, wrong JSDoc parameters etc,
let
whereconst
was more appropriate etc)