Skip to content

Conversation

CPerezz
Copy link

@CPerezz CPerezz commented Sep 23, 2025

🗒️ Description

When deploy_contract() is called with a stub parameter, it retrieves the existing contract from the chain and adds it to the allocation. However, the method was missing a return statement after handling the stub case, causing it to continue executing and attempt to deploy a new contract with the stub's bytecode.

This led to an assertion error when the retrieved bytecode (Bytes type) didn't match the expected types (Bytecode or Container) for deployment.

The fix adds a return statement after the stub handling block to properly exit the method and return the stub's contract address.

🔗 Related Issues or PRs

The related issue is the inclusion of stub contracts themseleves in #2073

✅ Checklist

  • All: Ran fast tox checks to avoid unnecessary CI fails, see also Code Standards and Enabling Pre-commit Checks:
    uvx --with=tox-uv tox -e lint,typecheck,spellcheck,markdownlint
  • All: PR title adheres to the repo standard - it will be used as the squash commit message and should start type(scope):.
  • All: Considered adding an entry to CHANGELOG.md.
  • All: Considered updating the online docs in the ./docs/ directory.
  • All: Set appropriate labels for the changes (only maintainers can apply labels).
  • Tests: Ran mkdocs serve locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.
  • Tests: For PRs implementing a missed test case, update the post-mortem document to add an entry the list.
  • Ported Tests: All converted JSON/YML tests from ethereum/tests or tests/static have been assigned @ported_from marker.

When deploy_contract() is called with a stub parameter, it retrieves the
existing contract from the chain and adds it to the allocation. However,
the method was missing a return statement after handling the stub case,
causing it to continue executing and attempt to deploy a new contract
with the stub's bytecode.

This led to an assertion error when the retrieved bytecode (Bytes type)
didn't match the expected types (Bytecode or Container) for deployment.

The fix adds a return statement after the stub handling block to properly
exit the method and return the stub's contract address.
Copy link
Contributor

@spencer-tb spencer-tb left a comment

Choose a reason for hiding this comment

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

LGTM! Thanks :)

@spencer-tb spencer-tb added type:chore Type: Chore scope:execute Scope: Changes to the execute command labels Sep 23, 2025
@spencer-tb spencer-tb changed the title fix(execute): Add missing return statement for stub contract deployment chore(execute): add missing return statement for stub contract deployment Sep 23, 2025
@CPerezz
Copy link
Author

CPerezz commented Sep 23, 2025

I'm surprised this wasn't caught by the tests. Am I using the feature on a weird way?? This all came from doing something like:

# Deploy factory using stub contract - NO HARDCODED VALUES
    # The stub "bloatnet_factory" must be provided via --address-stubs flag
    # The factory at that address MUST have:
    # - Slot 0: Number of deployed contracts
    # - Slot 1: Init code hash for CREATE2 address calculation
    factory_address = pre.deploy_contract(
        code=Bytecode(),  # Required parameter, but will be ignored for stubs
        stub="bloatnet_factory",
    )

Notice this benchmark is only called in execute mode within bloatnet benchmarks. So it might be a particularity of this situation. Anyways, I think the return was needed for more cases I'd say.

cc: @jochem-brouwer as you probably will find this with XEN

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope:execute Scope: Changes to the execute command type:chore Type: Chore
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants