-
Notifications
You must be signed in to change notification settings - Fork 87
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
Revert this old work around #746
Conversation
3b5a175
to
5fc54c4
Compare
Transactions CostsSizes and execution budgets for Hydra protocol transactions. Note that unlisted parameters are currently using
Script summary
Cost of Init Transaction
Cost of Commit TransactionCurrently only one UTxO per commit allowed (this is about to change soon)
Cost of CollectCom Transaction
Cost of Close Transaction
Cost of Contest Transaction
Cost of Abort TransactionSome variation because of random mixture of still initial and already committed outputs.
Cost of FanOut TransactionInvolves spending head output and burning head tokens. Uses ada-only UTxO for better comparability.
|
Test Results276 tests - 11 270 ✔️ - 11 14m 28s ⏱️ - 2m 26s Results for commit 4f96981. ± Comparison against base commit c71d925. This pull request removes 11 tests.
♻️ This comment has been updated with latest results. |
It seems that this old work-around is not needed anymore to run on Darwin systems.
When running the tests on os x with the Durable version we see the following errors: ``` test/Hydra/API/ServerSpec.hs:61:3: 1) Hydra.API.Server sends all sendOutput history to all connected clients after a restart uncaught exception: IOException of type PermissionDenied openFileFromDir: permission denied (Permission denied) To rerun use: --match "/Hydra.API.Server/sends all sendOutput history to all connected clients after a restart/" test/Hydra/PersistenceSpec.hs:43:5: 2) Hydra.Persistence.PersistenceIncremental is consistent after multiple append calls in presence of new-lines uncaught exception: IOException of type PermissionDenied openFileFromDir: permission denied (Permission denied) (after 4 tests) ``` Which is probably due to the fact that we write in the tmp directory, which is a bit special, and that the _Durable_ version pretends to deal with special directories but, maybe, not so much in this case. According to the documentation, `withBinaryFileDurable` behaves the same way as `withBinary` on Windows. On other systems it provides the following guarantees: > * It successfully closes the file in case of an asynchronous exception > * It reliably saves the file in the correct directory; including edge case situations like a different device being mounted to the current directory, or the current directory being renamed to some other name while the file is being used. > * It ensures durability by executing an fsync() call before closing the file handle So on Windows system, this commit does not change a thing. On other systems, in the context of appending history to the persistent storage of the node we are not impacted by removing the above _Durable_ features: * We only append to the end of the file * We open/close the file everytime we append an history item to it In this regard, the worst that could happen is some crash while appending one history item to the file which would result in this history item not written at all or partially written, in which case only the last line of the file would be corrupted. This is a situation we were already in with the previous version of the code. Hence this commit.
41756b1
to
4f96981
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy that we don't need more changes than these to make it work on macos
FIX PermissionDenied issues on os x
When running the tests on os x with the Durable version we see the following errors:
Which is probably due to the fact that we write in the tmp directory, which is a bit special,
and that the Durable version pretends to deal with special directories but, maybe, not so
much in this case.
According to the documentation,
withBinaryFileDurable
behaves the same way aswithBinary
on Windows. On other systems it provides the following guarantees:So on Windows system, this commit does not change a thing.
On other systems, in the context of appending history to the persistent storage of the node we are not impacted by removing the above Durable features:
In this regard, the worst that could happen is some crash while appending one history item to the file which would result in this history item not written at all or partially written, in which case only the last line of the file would be corrupted.
This is a situation we were already in with the previous version of the code. Hence this P.R..