Historically, active_work was configured globally and had the same value everywhere.
Now, active_work is adjusted when creating a DZKP validator, to have an appropriate value relative to the batch size.
Unfortunately, seq_join is often invoked as a free function, like this: seq_join(ctx.active_work(), ...). If there are multiple contexts in scope (e.g. a non-upgraded ctx and a DZKP-upgraded m_ctx), the active work used for seq_join may not match the validator-adjusted value.
Assuming we can avoid the dreaded 100013-related errors, it might be better to invoke seq_join as a helper on the context, so that the appropriate active work can be used automatically. Although, that may not improve things that much, since one could still do ctx.seq_join(/* futures referencing m_ctx */).
In any case, filing this as a reminder to revisit this, possibly doing some refactoring, or maybe just auditing seq_join calls.
Historically,
active_workwas configured globally and had the same value everywhere.Now,
active_workis adjusted when creating a DZKP validator, to have an appropriate value relative to the batch size.Unfortunately,
seq_joinis often invoked as a free function, like this:seq_join(ctx.active_work(), ...). If there are multiple contexts in scope (e.g. a non-upgradedctxand a DZKP-upgradedm_ctx), the active work used for seq_join may not match the validator-adjusted value.Assuming we can avoid the dreaded 100013-related errors, it might be better to invoke
seq_joinas a helper on the context, so that the appropriate active work can be used automatically. Although, that may not improve things that much, since one could still doctx.seq_join(/* futures referencing m_ctx */).In any case, filing this as a reminder to revisit this, possibly doing some refactoring, or maybe just auditing
seq_joincalls.