Bring back --no-artificial-delay

Developers
1

Related: Disable BlockTime

There used to be a --no-artificial-delay flag on dfx start. This was very nice for integration tests, where you want to run your tests against the canister locally to emulate production as closely as possible.

Without that flag, running 100s or 1000s of tests will be infeasible in short amounts of time. At Demergent Labs we’re about to start in-depth property tests for the Azle and Kybra CDKs, where we generate arbitraries that create many many inputs, possibly 100s, 1000s, or even more. Having to wait for update calls to finish locally I foresee being a major source of unnecessary latency in our tests.

And I know about other testing paradigms where you might separate code from your canister to test it separately. That may be sufficient for some use cases, but I also want the ability to test my code directly from within a canister, as this mimics the production environment much more closely.

@Seb @paulyoung @quint you may have experienced the need for this before as well, I would love to know if you still want this functionality.

10 Likes
2

+1 to this. I’m writing some unit tests right now and it isn’t feasible to do this locally right now because it takes so long. --no-artificial-delay feels extremely important for anyone doing testing locally.

2 Likes
3

+1 Bring it back or make the value configurable. Makes zero sense to restrict us here

4 Likes
4

Related PR:

It seems that over a year ago the flag was removed but the net result is that the default changed to 600ms vs 500ms when using the flag.

The comment says the 600ms is the value used in the production network.

3 Likes
5

I personally also would like to see this. I’ll bring it up with the team

4 Likes
6

We decided that we’d be happy to re-introduce the --no-artificial-delay flag. We’d get to it soon-ish (whenever someone feels they have the time), but I’d also be happy to approve a PR wink wink nudge nudge

3 Likes
7

What would it do though? It used to set the delay to 500ms. The delay is currently 600ms. Are you proposing it set the delay to 0ms?

8

How about provide an interface saying “dfx config set --global <file.json>”

And replace “~/.dfx/config/xxx.config”

9

I think for extensive test suites that would be perfect. I also wouldn’t mind being able to set arbitrary values so people would type e.g. --artificial-delay 17, and it would have a default value of the current 500ms

We were thinking of a global settings file already for some customisation. Sounds like a good idea to me.

2 Likes
10

I still want this functionality.

1 Like
11

Yes let us set it to 0

3 Likes
12

In case this hasn’t been solved yet (I wasn’t able to find a solution), I created an discussion in the sdk repo for this.

I know the SDK team is prioritizing some developer quality of life improvements in Q2, so feel free to upvote this issue if it affects you.

7 Likes
13

(Still) not solved yet, but currently planned to be completed until the end of the month.

Note to self: internal ticket

6 Likes
14

The feature has been added in #3047 and will be included in the next release of dfx.

4 Likes
15

Thank you very much!

16

And for the impatient ones, you can use it already now:

git checkout git@github.com:dfinity/sdk.git
cd sdk
cargo build
alias dfx=$(pwd)/target/debug/dfx
1 Like