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

Fix importing contract crates into other crates for testing #1364

Merged
merged 2 commits into from
Oct 8, 2024

Conversation

leighmcculloch
Copy link
Member

@leighmcculloch leighmcculloch commented Oct 8, 2024

What

Change two locations of the soroban-sdk-macros which were gated on the contract crates testutils feature, to be gated on the SDK's testutils feature.

Why

Recently I introduced a bug into the sdk across two changes:

The bug was that I changed how some code was gated to be gated on whether the contract's testutils feature was enabled, rather than on the SDKs.

Sometime ago in the following issue I changed how all of a contract's testutils are enabled/disabled, by being enabled/disabled by the SDK's testutils feature:

That change was good, it fixed a horrid issue with testing contracts where you could have some contracts in testutils mode, and others not, leading to strange errors when importing native contracts for testing.

However, when I worked on the two issues above, I inadvertently forgot that we had changed the structure of how testutils code got enabled, and I introduced across those two PRs two new locations where we followed the old pattern and gated on the contract feature set, not the SDKs.

For most users this will have presented no issues because there all of these testutilities are always enabled in a contract's own tests. This masked the issue in all of our own tests, but broke setups like fuzzing where the contract gets imported. All of our fuzz projects unfortunately don't currently build the fuzz components, and so this got missed until someone (me) tried to use them.

Known limitations

This change doesn't introduce a test to detect this type of breakage. I think the way we can detect this in the future is have our pre-existing test vector build as part of CI. This issue is tracking that follow up work:

Merging

This fix is targeting main, but we need a similar fix to target v21, because part of this bug was introduced into v21.7.2. Once this change merges to main, I will partially cherry-pick it into a backport patch release.

@leighmcculloch leighmcculloch added this pull request to the merge queue Oct 8, 2024
Merged via the queue into main with commit 1eaa5d8 Oct 8, 2024
16 checks passed
@leighmcculloch leighmcculloch deleted the fix-testutils-enabled-feature-in-wrong-layer branch October 8, 2024 23:38
leighmcculloch added a commit that referenced this pull request Oct 9, 2024
### What

Change two locations of the soroban-sdk-macros which were gated on the
contract crates `testutils` feature, to be gated on the SDK's
`testutils` feature.

### Why

Recently I introduced a bug into the sdk across two changes:
- #1344
- #1336

The bug was that I changed how some code was gated to be gated on
whether the contract's `testutils` feature was enabled, rather than on
the SDKs.

Sometime ago in the following issue I changed how all of a contract's
testutils are enabled/disabled, by being enabled/disabled by the SDK's
testutils feature:
- #1301

That change was good, it fixed a horrid issue with testing contracts
where you could have some contracts in testutils mode, and others not,
leading to strange errors when importing native contracts for testing.

However, when I worked on the two issues above, I inadvertently forgot
that we had changed the structure of how testutils code got enabled, and
I introduced across those two PRs two new locations where we followed
the old pattern and gated on the contract feature set, not the SDKs.

For most users this will have presented no issues because there all of
these testutilities are always enabled in a contract's own tests. This
masked the issue in all of our own tests, but broke setups like fuzzing
where the contract gets imported. All of our fuzz projects unfortunately
don't currently build the fuzz components, and so this got missed until
someone (me) tried to use them.

### Known limitations

This change doesn't introduce a test to detect this type of breakage. I
think the way we can detect this in the future is have our pre-existing
test vector build as part of CI. This issue is tracking that follow up
work:
- #1363

### Merging

This fix is targeting main, but we need a similar fix to target v21,
because part of this bug was introduced into v21.7.2. Once this change
merges to main, I will partially cherry-pick it into a backport patch
release.

(cherry picked from commit 1eaa5d8)
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

Successfully merging this pull request may close these issues.

2 participants