Tune snapshot generation in TxTrace tests #1524
Labels
Comments
ch1bo
added
the
follow-up
ch1bo
added a commit
that referenced
this issue
Jul 23, 2024
This PR adds "incremental decommits" to the Hydra Head protocol, which
allows users to take funds out of an open Head.
- New API endpoint `/decommit` which accepts a "Decommit transaction",
that spends some UTxO and whatever outputs it produces will be made
available on the L1. This can be also done through a new `Decommit`
client input and new server outputs `DecommitRequested`,
`DecommitApproved` and `DecommitFinalized`, as well as `DecommitInvalid`
to inform about status of the decommit.
- Decommits are first approved in a snapshot on L2 via a new network
message `ReqDec`, before a new `decrementTx` can be posted and observed
on-chain.
- Only one decommit can be processed at a given time.
- Update documentation and added how-to about how to use this.
- Acknowledged specification changes by "clearing" of
$\textcolor{red}{\\red}$ areas covered by this implementation in the
specification.
- End-to-end test covering the main scenario of decommitting funds.
- Added mutation tests for Decrement, Close and Contest to cover all
on-chain-verification changes.
- Enhanced `TxTrace` tests to test decrements with various snapshots and
their interaction with close/contest and fanout of a head.
---
* [x] CHANGELOG updated
* [x] Documentation updated
* [x] Haddocks updated
* [x] New TODOs explained hereafter
- Two FIXMEs covered by #1524
- TODO in HeadLogic coverd by #1502
- TODO in tx-cost how we could improve the benchmark output (not
crucial)
- TODO in head logic about rollbacks .. actually something we need to
consider with #199 too
ch1bo
added
red bin
and removed
follow-up
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Follow-up of #1057
Why
When implementing incremental decommits in #1344, we significantly increased the complexity of snapshots used in the
TxTracetests and switched from a "ahead of time" to a "just in time" generation of snapshots to decrement, close and contest a head with.This resulted in complicated generation and lots of filtering through preconditions, making the tests less efficient and hard to maintain.
Also, the generated traces are not covering all "interesting" situations within reasonable max successes and we needed to disable
checkCoverageonprop_traces.What
prop_traces, re-enablecheckCoverageand use the same number of tests in theprop_runActionsHow
Decrement,CloseandContestjust pick from an available list of snapshots in the modelpreconditionandvalidFailingAction-> this reduces discardsThe text was updated successfully, but these errors were encountered: