You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Building on #857 and #858 (and extending #576), the base class implementation of workload modules could be smarter.
Currently, this idea is only meaningful for workload modules that submit a single TX when enabled (so no batches).
Expected Behavior
Based on a schema like this:
workload:
module: mySimpleWorkload.jsarguments:
myArg1: value1builder: # special, reserved argument name for the base classtargetContract: myContractIDtargetFunction: transferarguments:
- name: sourcevalue: account1# values could reference arguments above using YAML anchors and aliases
- name: targetvalue: account2
- name: amountvalue: 100timeout: 5000# ...
a smarter workload module base class could be implemented that can partially/completely build a TX. In this case, reusing a builder instance is definitely a good idea.
Your Environment
Version used: v0.3.1
The text was updated successfully, but these errors were encountered:
Context
Building on #857 and #858 (and extending #576), the base class implementation of workload modules could be smarter.
Currently, this idea is only meaningful for workload modules that submit a single TX when enabled (so no batches).
Expected Behavior
Based on a schema like this:
a smarter workload module base class could be implemented that can partially/completely build a TX. In this case, reusing a builder instance is definitely a good idea.
Your Environment
The text was updated successfully, but these errors were encountered: