-
Notifications
You must be signed in to change notification settings - Fork 721
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
Fully remove the cli intermediate TxBody format #4713
Fully remove the cli intermediate TxBody format #4713
Conversation
There are some golden test failures. |
2c5e96e
to
a52fa5e
Compare
Fixed |
8e29465
to
053db1c
Compare
053db1c
to
93097ab
Compare
93097ab
to
ec4cb25
Compare
ec4cb25
to
34ad3dd
Compare
34ad3dd
to
8182666
Compare
, teDescription = fromMaybe (textEnvelopeDefaultDescr a) mbDescr | ||
, teRawCBOR = serialiseToCBOR a | ||
} | ||
where | ||
teType :: [TextEnvelopeType] -> TextEnvelopeType | ||
teType [] = "" | ||
teType (x : _) = x |
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.
Paraphrasing, the teType
is the first in the list or the empty string. If there original list had more than one, what is the significance of the ordering?
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.
It will default to the first in the list. When reading a TextEnvelope
file, it will check for all the types in the list hence preserving backwards compatibility. However when producing a TextEnvelope
we simply default to the first in the list if there is more than one teType
.
decodeKeyOrBootstrapWitness era bs = | ||
case CBOR.decodeAnnotator "KeyWitness" fromCBOR (LBS.fromStrict bs) of | ||
Right keyWit -> return $ ShelleyKeyWitness era keyWit | ||
Left{} -> |
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.
What's the reason for ignoring Left
payload?
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.
So that we can try to deserialize a bootstrap witness
("roundtrip " <> (fromString . Text.unpack $ renderEra aEra) <> " TxBody envelope") | ||
("roundtrip " <> (fromString . Text.unpack $ renderEra aEra) <> " TxBody envelope") |
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.
Prefer:
("roundtrip " <> fromString (Text.unpack (renderEra aEra)) <> " TxBody envelope")
("roundtrip " <> fromString (Text.unpack (renderEra aEra)) <> " TxBody envelope")
or:
("roundtrip " <> fromString (Text.unpack $ renderEra aEra) <> " TxBody envelope")
("roundtrip " <> fromString (Text.unpack $ renderEra aEra) <> " TxBody envelope")
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.
👍 Done
@@ -108,7 +108,7 @@ instance FromCBOR Certificate where | |||
fromCBOR = fromShelleyCertificate <$> fromCBOR | |||
|
|||
instance HasTextEnvelope Certificate where | |||
textEnvelopeType _ = "CertificateShelley" |
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.
"CertificateShelley"
and the other textEnvelopeType
names are all magic IDs and they are assumed to be unique throughout the code.
It would be better to have all those unique ID in one place.
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.
What do you have in mind?
There should be an issue for this PR. Is there any document that captures the requirements for the CLI on-disk-formats ? Reading input and writing output formats is the core functionality of the CLI. The CLI does different task (crate TX body, sign TX, balance TX) while the ledger only deals |
8182666
to
c4c8a63
Compare
I created an issue created: #4814
Yes.
We should stick to the CDDL format for tx ondisk. This is to allow compatibility for existing libraries that expect the transaction to be in the CDDL format. This whole issue arose out of this incompatibility (see #3370)
No, but for now we are opting to not deviate from the CDDL format
None as of this PR regarding transaction body formats.
Not as of this PR
I highly doubt this
This would be a great task for you to spearhead.
Have a look at #3370 |
c4c8a63
to
5607d15
Compare
113bd3d
to
0d89fdd
Compare
`TextEnvelopeType`s. This allows for easy backwards compatibility for the `TextEnvelopeType`s that were introduced to distinguish between the cli intermediate `TxBody` format and the CDDL format.
Implement allTxBodyEnvelopeRoundtrips which roundtrip tests the TxBody TextEnvelope format in all eras Update shelley era properties to check for the correct TextEnvelopeType
Update HasTextEnvelope (Tx era) instance to be backwards compatible with `TextEnvelopeType`s introduced to distinguish between the CDDL format and the intermediate cli txbody format Update the SerialiseAsCBOR (KeyWitness era) instance to use the ledger's CDDL format Update checkTextEnvelopeFormat to accept `[TextEnvelopeType]` as we can now specify multiple `TextEnvelopeType`s in a given `HasTextEnvelope` instance
0d89fdd
to
a931959
Compare
a931959
to
bb69f40
Compare
Resolved by: IntersectMBO/cardano-api@e739675 |
Resolves #4814
In this PR we fully remove support for the intermediate cli tx body format. As a result we make the following changes:
HasTextEnvelope
type class as follows:textEnvelopeType :: AsType a -> TextEnvelopeType
->textEnvelopeType :: AsType a -> [TextEnvelopeType]
. We do this so we can have backwards compatibility for theTextEnvelopeType
s that were introduced when we had to differentiate between the intermediate format and the CDDL format.Cardano.Api.SerialiseLedgerCddl
as we do not want to maintain a separate type for the CDDL format. We should default to the CDDL format via theTextEnvelope
typeCardano.Api.TxBodyInstances
module because the "trick" we use to avoid the txbody intermediate format, is to convert theTxBody
into an unsignedTx
.