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

[Refactor] simplify and unify the storage setup for tests #2590

Open
wants to merge 2 commits into
base: staging
Choose a base branch
from

Conversation

ljedrz
Copy link
Collaborator

@ljedrz ljedrz commented Jan 10, 2025

The hybrid nature of our storage makes testing it tricky, and there are several spots where we are currently using a mix of in-memory and persistent storage, which complicates things further. The changes proposed in this PR are something that I've hoped to see in snarkVM for a while now, and since some other, concurrent snarkVM work requires a stricter separation between the storage variants, it was a good opportunity to finally propose them.

The following is a rough summary of these changes:

  • all the tests now implicitly either use the persistent storage or the in-memory one; there is no mixing, unless it's done explicitly
  • as far as storage is concerned, all the tests can now run concurrently
  • the open_(.*)testing methods are no longer needed, there is no test special-casing for rocksdb either
  • the open methods no longer require S to be Clone
  • instead of a static DB, there is now a static DATABASES, which has more than a single member only in tests
  • the ledger-with-rocksdb CI job should be runnable again

What this fixes:

  • there are currently several storage-related tests that use the serial attribute, which doesn't affect the use of static objects (specifically static DB), meaning the tests involving RocksDB storage can get cross-contaminated
  • some tests are currently (re)using the same folder that's used in --dev mode, which can lead to cross-contamination and/or can overwrite storage related to development tests
  • one of the tests related to stacks failed due to the wrong storage type being used

Future improvements:

  • if the open methods for the stores didn't rely so much on StorageMode (i.e. if we could use an instance of actual storage to open the stores), we wouldn't need static DATABASES (or DB, as is the case currently); that being said, I'd prefer it to be done separately
  • we currently only store the production genesis block, but doing the same for the testnet one would speed up some of the tests (it would allow us to run some of the slower tests in --release mode)

Requires: ProvableHQ/aleo-std#12

@ljedrz ljedrz force-pushed the refactor/simplified_unified_test_storage branch from ef9c5ea to 6868d4b Compare January 13, 2025 11:00
@ljedrz ljedrz marked this pull request as ready for review January 14, 2025 11:19
@ljedrz
Copy link
Collaborator Author

ljedrz commented Jan 14, 2025

While that one program (rand_chacha_check) in test_vm_execute_and_finalize is returning a different outcome than the expectation regardless of features (rocksdb, test), I'm not sure why it happens just yet, but the PR may already be reviewed, and hopefully the cause will be revealed in the process.

For reference, this is the one mismatch:

============================================================
TEST
------------------------------------------------------------
program: test_rand.aleo
function: rand_chacha_check
inputs:
- 1field
- true

============================================================
EXPECTED
------------------------------------------------------------
verified: true
execute:
  test_rand.aleo/rand_chacha_check:
    outputs:
    - '{"type":"future","id":"818878742790741579153893179075772445872751227433677932822653185952935999557field","value":"{\n  program_id: test_rand.aleo,\n  function_name: rand_chacha_check,\n  arguments: [\n    1field,\n    true\n  ]\n}"}'
speculate: the execution was rejected
add_next_block: succeeded.

============================================================
ACTUAL
------------------------------------------------------------
verified: true
execute:
  test_rand.aleo/rand_chacha_check:
    outputs:
    - '{"type":"future","id":"818878742790741579153893179075772445872751227433677932822653185952935999557field","value":"{\n  program_id: test_rand.aleo,\n  function_name: rand_chacha_check,\n  arguments: [\n    1field,\n    true\n  ]\n}"}'
speculate: the execution was accepted
add_next_block: succeeded.

============================================================

@ljedrz
Copy link
Collaborator Author

ljedrz commented Jan 14, 2025

I have a branch ready with a StorageMode::Test proposal, which would reduce the reliance of this PR on the test feature. I'd be happy to update this PR based on it if we can release an update to aleo-std soon.

@ljedrz
Copy link
Collaborator Author

ljedrz commented Jan 14, 2025

Update: I no longer have that one test mismatch with updated aleo-std, so I'll double-check the other tests and update this PR shortly.

@ljedrz
Copy link
Collaborator Author

ljedrz commented Jan 15, 2025

I updated the PR to use a new aleo-std-storage feature which makes things simpler and more explicit; it hasn't been merged yet, so there are temporarily some dependencies on a specific branch, but other than that this PR is ready for review now.

@ljedrz ljedrz marked this pull request as ready for review January 15, 2025 09:18
@ljedrz ljedrz force-pushed the refactor/simplified_unified_test_storage branch 3 times, most recently from ecc404c to d64328a Compare February 13, 2025 14:38
@vicsn vicsn requested review from d0cd and vicsn February 13, 2025 15:47
Copy link
Collaborator

@vicsn vicsn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, once this and aleo-std are approved you can update the cargo.toml and we may need Ray for publishing aleo-std.

@ljedrz ljedrz force-pushed the refactor/simplified_unified_test_storage branch from d64328a to 58ab962 Compare February 14, 2025 14:48
@vicsn vicsn added the v3.4.0 label Feb 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants