Skip to content
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

Open
michalrus opened this issue Nov 7, 2024 · 1 comment
Open
Assignees
Milestone

Comments

@michalrus
Copy link
Collaborator

michalrus commented Nov 7, 2024

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:

  1. purely construct only the errors in Haskell,
  2. serialize them there,
  3. and then try to deserialize them with our Rust code,
  4. and compare both representations?

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:

@michalrus michalrus added this to the v0.1 milestone Nov 7, 2024
@michalrus michalrus self-assigned this Nov 7, 2024
michalrus added a commit that referenced this issue Nov 27, 2024
michalrus added a commit that referenced this issue Nov 28, 2024
@michalrus
Copy link
Collaborator Author

I'm going to reassign this to @ginnun after:

The Haskell tool is available from our devshell to test against.

@michalrus michalrus assigned ginnun and unassigned michalrus Nov 29, 2024
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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants