Consensus ignores "consensusDelay" config

[nnikolash]

Steps to reproduce:

• Deploy new chain
• Perform any action, which results into consensus being skipped. E.g., wasp-cli chain deposit '0x02::iota::IOTA|10' without having enough funds will result in an issue with min fee and thus skip of consensus.
• See that consensus is immediatelly retried no matter which value is in consensusDelay.

2025-09-15T02:23:30-07:00       INFO    Chains.0x92dbca61.C-0x2f797d34.LI-286           Consensus started, received {cons.inputProposal: baseAliasOutput={StateAnchor, obj{id=0x92dbca61db63653edcd05f98ff6cf639fd9bab68aa3d6b8410151f8d520f1188, version=124, digest=DXFRJM9yAMxScAie5AB49YeWuycg2GZGrgxNRBs47Ka7}}}
2025-09-15T02:23:30-07:00       ERROR   Chains.0x92dbca61.C-0x2f797d34.LI-286.VM        panic before request execution (reqid: 0xddbcfcfeb104c3f81589d630ff303e79c6164a481d8fc716ac787f92aabc7d3e): user doesn't have enough on-chain funds to cover the minimum fee for processing this request
2025-09-15T02:23:30-07:00       INFO    Chains.0x92dbca61.C-0x2f797d34.LI-286.VM        request skipped (ignored) by the VM: 0xddbcfcfeb104c3f81589d630ff303e79c6164a481d8fc716ac787f92aabc7d3e, reason: user doesn't have enough on-chain funds to cover the minimum fee for processing this request
2025-09-15T02:23:30-07:00       INFO    Chains.0x92dbca61.C-0x2f797d34.LI-286           Terminating consensus with status=Skipped, 0 requests processed.
2025-09-15T02:23:30-07:00       INFO    Chains.0x92dbca61.C-0x2f797d34.LI-287           Consensus started, received {cons.inputProposal: baseAliasOutput={StateAnchor, obj{id=0x92dbca61db63653edcd05f98ff6cf639fd9bab68aa3d6b8410151f8d520f1188, version=124, digest=DXFRJM9yAMxScAie5AB49YeWuycg2GZGrgxNRBs47Ka7}}}
2025-09-15T02:23:30-07:00       ERROR   Chains.0x92dbca61.C-0x2f797d34.LI-287.VM        panic before request execution (reqid: 0xddbcfcfeb104c3f81589d630ff303e79c6164a481d8fc716ac787f92aabc7d3e): user doesn't have enough on-chain funds to cover the minimum fee for processing this request
2025-09-15T02:23:30-07:00       INFO    Chains.0x92dbca61.C-0x2f797d34.LI-287.VM        request skipped (ignored) by the VM: 0xddbcfcfeb104c3f81589d630ff303e79c6164a481d8fc716ac787f92aabc7d3e, reason: user doesn't have enough on-chain funds to cover the minimum fee for processing this request
2025-09-15T02:23:30-07:00       INFO    Chains.0x92dbca61.C-0x2f797d34.LI-287           Terminating consensus with status=Skipped, 0 requests processed.

[nnikolash]

Here is the flow of issue:

• Consesus skipped
• inputConsensusOutputSkip passed to cmtlog
• The result of cmtlog is then passed to chainMgrImpl::handleCmtLogOutput
• chainMgrImpl::ensureNeedConsensus
• chainNodeImpl::handleNeedConsensus called
• needConsensusCB called, which starts new consensus instance

(lines may be a little imprecise due to prints)

goroutine 364 [running]:
github.com/iotaledger/wasp/v2/packages/chain/cons/gr.(*ConsGr).Input(0xc000309200?, 0xc000466a20?, 0xc00050e601?, 0x4f7c6f?)
        /home/nikita/iota/wasp/packages/chain/cons/gr/gr.go:244 +0x12a
github.com/iotaledger/wasp/v2/packages/chain.(*chainNodeImpl).ensureConsensusInput(0xc0002f6a88, {0x288f970?, 0xc00050e6e0?}, 0xc002bfd140)
        /home/nikita/iota/wasp/packages/chain/node.go:785 +0x128
github.com/iotaledger/wasp/v2/packages/chain.(*chainNodeImpl).handleNeedConsensus.func1({0x17, 0x76, 0x59, 0x88, 0x8c, 0x32, 0x10, 0x2f, 0xdc, 0x9e, ...}, ...)
        /home/nikita/iota/wasp/packages/chain/node.go:678 +0x25
github.com/iotaledger/hive.go/ds/shrinkingmap.(*ShrinkingMap[...]).ForEach(0x28d0420, 0xc0003d1730)
        /home/nikita/go/pkg/mod/github.com/iotaledger/hive.go/ds@v0.0.0-20250409140545-e1a365dbea74/shrinkingmap/shrinkingmap.go:174 +0x2c2
github.com/iotaledger/wasp/v2/packages/chain.(*chainNodeImpl).handleNeedConsensus(0xc0002f6a88, {0x288f970?, 0xc00050e6e0?}, 0xc000594e10)
        /home/nikita/iota/wasp/packages/chain/node.go:677 +0x55
github.com/iotaledger/wasp/v2/packages/chain.createChainManager.func1(0xc000594e10)
        /home/nikita/iota/wasp/packages/chain/node.go:1370 +0xbb
github.com/iotaledger/wasp/v2/packages/chain/chainmanager.(*chainMgrImpl).ensureNeedConsensus(0xc00055a780, 0xc000565800, {0x1fa82e0, 0xc002cb4450})
        /home/nikita/iota/wasp/packages/chain/chainmanager/chain_manager.go:594 +0x46c
github.com/iotaledger/wasp/v2/packages/chain/chainmanager.(*chainMgrImpl).handleCmtLogOutput(0xc00055a780, 0xc000565800, {0x28a0450, 0xc0005c9a00})
        /home/nikita/iota/wasp/packages/chain/chainmanager/chain_manager.go:518 +0xdd
github.com/iotaledger/wasp/v2/packages/chain/chainmanager.(*chainMgrImpl).withCmtLog(0xc00055a780, {0x17, 0x76, 0x59, 0x88, 0x8c, 0x32, 0x10, 0x2f, 0xdc, ...}, ...)
        /home/nikita/iota/wasp/packages/chain/chainmanager/chain_manager.go:639 +0x119
github.com/iotaledger/wasp/v2/packages/chain/chainmanager.(*chainMgrImpl).handleInputConsensusOutputSkip(...)
        /home/nikita/iota/wasp/packages/chain/chainmanager/chain_manager.go:443
github.com/iotaledger/wasp/v2/packages/chain/chainmanager.(*chainMgrImpl).Input(0xc002c85020?, {0x1f2f460?, 0xc002c85020?})
        /home/nikita/iota/wasp/packages/chain/chainmanager/chain_manager.go:291 +0x92
github.com/iotaledger/wasp/v2/packages/gpa.(*OwnHandler).Input(0xc00002c080, {0x1f2f460?, 0xc002c85020?})
        /home/nikita/iota/wasp/packages/gpa/own_handler.go:30 +0x2b
github.com/iotaledger/wasp/v2/packages/gpa.(*ackHandler).Input(0xc00070ac60, {0x1f2f460?, 0xc002c85020?})
        /home/nikita/iota/wasp/packages/gpa/ack_handler.go:75 +0x54
github.com/iotaledger/wasp/v2/packages/chain.(*chainNodeImpl).handleConsensusOutput(0xc0002f6a88, 0xc0005c4f70)
        /home/nikita/iota/wasp/packages/chain/node.go:750 +0x132
github.com/iotaledger/wasp/v2/packages/chain.(*chainNodeImpl).run(0xc0002f6a88, {0x288f970, 0xc00050e6e0}, 0xc00058c090?)
        /home/nikita/iota/wasp/packages/chain/node.go:466 +0x9e5
created by github.com/iotaledger/wasp/v2/packages/chain.initializeOperationalChain in goroutine 41
        /home/nikita/iota/wasp/packages/chain/node.go:1302 +0xdb7

To at least visibly fix the issue, I've created a PR with debug code (not a fix, just a demo). It does three things:

• Disables calling needConsensusCB upon update of needConsensusMap. This stops infinite cycle.
• Except, it enables needConsensusCB for one specific case: when we have zero number of instances of cmtlog. We need to know at least one. Otherwise inputCanPropose event does not do anything (withAllCmtLogs has no instances to iterate).
• Adds call to needConsensusCB after inputCanPropose.

So instead of calling needConsensusCB on update we call it on time tick.

This is not a fix, just a demo of how desired effect can be achieved. But this most likely break other stuff, which I'm not aware of, as the analysis of the problem was too shallow. We need consultation of @kape1395 on how to better solve this issue.