-
Notifications
You must be signed in to change notification settings - Fork 217
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
1892: Withdrawals as part of core and API transactions r=KtorZ a=KtorZ # Issue Number <!-- Put here a reference to the issue this PR relates to and which requirements it tackles --> #1881 # Overview <!-- Detail in a few bullet points the work accomplished in this PR --> - 589609e 📍 **factor out common code in database migration** Turns out that adding column is a pretty common and straighfordward migration. I originally intended to add a new column to the TxMeta table, hence the refactor. In the end, I've used a different table for withdrawals, but the refactor is still worth it as it is IMO. - e9e516c 📍 **add withdrawals to API & core transaction data types** Still to be done: withdrawals must be discovered when processing blocks - ff58489 📍 **upgrade Byron & Jormungandr compatibility code with empty withdrawals** Withdrawals are only a thing in Shelley, so for this targets, we can safely replace them by empty lists - 533b787 📍 **wire withdrawals in Shelley compatibility code** Here, we extract withdrawals directly from the TxBody, the conversion is straightforward - e2e6fbb 📍 **include withdrawals where relevant in test and arbitrary generators** - 4b6eaba 📍 **add withdrawals to the API Swagger specification** We represent them as a list and not a key:value map with stake address as key because clients typically don't know the stake address associated with their wallet, so it'd be quite impractical for them to access this data if returned as a map... # Comments <!-- Additional comments or screenshots to attach if any -->⚠️ Sorry, the PR spans over many files because I needed to add a new class constraints `DecodeStakeAddress` which goes side-by-side with the current `DecodeAddress`. <!-- Don't forget to: ✓ Self-review your changes to make sure nothing unexpected slipped through ✓ Assign yourself to the PR ✓ Assign one or several reviewer(s) ✓ Once created, link this PR to its corresponding ticket ✓ Assign the PR to a corresponding milestone ✓ Acknowledge any changes required to the Wiki --> 1895: hydra: Prevent caching of shelley integration test failures r=KtorZ a=rvl ### Issue Number Not sure. ### Overview This change causes integration tests to be re-run whenever the git revision changes, even if everything else is identical. Since these tests tend to fail a lot, we don't want to cache false failures. Also increase the minimum severity for integration test logging, because debug level produces quite a lot of output. Co-authored-by: KtorZ <[email protected]> Co-authored-by: IOHK <[email protected]> Co-authored-by: Rodney Lorrimar <[email protected]>
- Loading branch information
Showing
54 changed files
with
806 additions
and
271 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.