-
Notifications
You must be signed in to change notification settings - Fork 0
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
Verify our Rust CBOR error deserializer against Haskell's serializer #42
Milestone
Comments
michalrus
added a commit
that referenced
this issue
Nov 15, 2024
michalrus
added a commit
that referenced
this issue
Nov 21, 2024
michalrus
added a commit
that referenced
this issue
Nov 22, 2024
michalrus
added a commit
that referenced
this issue
Nov 25, 2024
michalrus
added a commit
that referenced
this issue
Nov 25, 2024
michalrus
added a commit
that referenced
this issue
Nov 25, 2024
michalrus
added a commit
that referenced
this issue
Nov 25, 2024
michalrus
added a commit
that referenced
this issue
Nov 27, 2024
michalrus
added a commit
that referenced
this issue
Nov 28, 2024
I'm going to reassign this to @ginnun after:
The Haskell tool is available from our devshell to test against. |
michalrus
added a commit
that referenced
this issue
Dec 3, 2024
Related to #42. Follow up to #93. I realized that we potentially have an infinite loop (although each iteration slept for 1 s). If a user broke the deployment so that `testgen-hs` became inaccessible, the request to deserialize a CBOR would never be fulfilled, not even with an error. We only returned deserialization errors from a working Haskell tool itself. Lower-level errors were only logged to our `stdout`. After this change, a "repeated internal failure" is returned after the *2nd* attempt to deserialize the same request fails on a lower level (e.g. because the child binary cannot be found, because someone moved it).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In a huddle with @ginnun, we had an idea. 💡
Since it would be hard to generate all possible errors by constructing invalid transactions with
cardano-cli conway transaction build-raw
, why not just:This could even be done quite dynamically. They may even already have QuickCheck random generators for the errors, that we could reuse.
The representations should be the same for all errors, and then after running thousands of such property checks, we can be reasonably sure that we are returning the same errors as
cardano-submit-api
.We could also use the
cardano-api-submit
error serializer (CBOR → ADT → JSON), to compare if we are constructing the JSONs in exactly the same way, based on the deserialized ADT.To run this on CI, we’ll need #34 first, but @michalrus can already start working on this one locally.
Required by:
The text was updated successfully, but these errors were encountered: