I worked an an itest for this a few years ago: #7228

That work got stalled waiting on #7241, and I never picked it up again.

Yeah would be nice to revive #7228, plus I don't think we need to mine that many blocks in the itest, this value can be changed using a build tag such that for integration this can be set to a much smaller value.

Yeah would be nice to revive #7228, plus I don't think we need to mine that many blocks in the itest, this value can be changed using a build tag such that for integration this can be set to a much smaller value.

That makes sense! I was thinking of using a build tag to override MaxWaitNumBlocksFundingConf for integration tests, reducing it to a much lower value so we don’t have to mine too many blocks while still triggering the timeout case. Would this approach be a good way to minimize block mining?

You can make it a configurable value, but expose the flag to actually configure it only in dev/integration test builds by adding it here:

You can make it a configurable value, but expose the flag to actually configure it only in dev/integration test builds by adding it here:

lnd/lncfg/dev_integration.go

Line 23 in ab7aae0

type DevConfig struct {

Is this what you meant—making MaxWaitNumBlocksFundingConf configurable in DevConfig and exposing a flag only for dev/integration builds while keeping 2016 as the default for production?

Could I be assigned to this issue if it's available to work on?

@Rakshitsinghhh are you wanting to work on this issue or can @NishantBansal2003 work on it?

Hi @Crypt-iQ, I haven't received a response from @Rakshitsinghhh yet. Would you prefer that I start working on this issue, or should I wait for his input? Thanks!

Hi @Crypt-iQ, I haven't received a response from @Rakshitsinghhh yet. Would you prefer that I start working on this issue, or should I wait for his input? Thanks!

It's been two days, you can go ahead and take it 👍