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

Future after IgnitionModule #812

Open
alcuadrado opened this issue Sep 23, 2024 · 2 comments · May be fixed by #828
Open

Future after IgnitionModule #812

alcuadrado opened this issue Sep 23, 2024 · 2 comments · May be fixed by #828
Assignees
Labels
type:feature Fetaure request

Comments

@alcuadrado
Copy link
Member

Describe the feature

Problem

In some situations, a user needs to express that a Future should only be executed after an IgnitionModule has been executed.

We have already covered this for one case, where the Future depends on a ContractFuture exported by the IgnitionModule, as the Future implicitly depends on the entire IgnitionModule (what we jokingly call The Malaga rule).

There are cases where no ContractFuture is exported from the IgnitionModule, and you still need to be able to express this. Right now, this leads to a workaround where a ContractFuture is unnecessarily defined and exported, as shown by The Graph's module definitions.

Solution

We could have an explicit way to express "after module".

A possible syntax could be something like:

const MyModule = require("./module.js");

// ...
const foo = m.contract("Foo", [], {after: [MyModule]});

This could be quickly done by adding all the futures as dependencies of foo, but it is probably worth making it a first-class citizen to be able to properly communicate and display it in the visualize task.

For future reference

I already validated this with the team at The Graph here.

Search terms

modules

@alcuadrado alcuadrado added the type:feature Fetaure request label Sep 23, 2024
@zoeyTM zoeyTM self-assigned this Oct 8, 2024
@vessenes
Copy link

Interesting timing. I was just wishing for this. Here's my use case in case you care about user stories:

I am deploying a fairly large set of contracts and data in a test environment with automining. There are 622 transactions in my deploy.

Some of my contracts rely on blockchain timing; automining increments the clock a little, and my local hardhat node ends up 10 minutes or so ahead of wall time. This causes terrible problems during testing, so I'd like to be able to set the time on the chain manually after we're all done with our deploy.

@zoeyTM
Copy link
Contributor

zoeyTM commented Oct 16, 2024

Hi @vessenes , I don't think the problem you're describing is impacted by this issue actually. I'd look through the Hardhat Network docs and see if anything there might help you. Specifically, either evm_increasetime or evm_setnextblocktimestamp I think might help you.

@zoeyTM zoeyTM linked a pull request Nov 1, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:feature Fetaure request
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

3 participants