Peter Broadhurst

I think there is a significant architectural point to consider, when you take a few of the above requirements into account. Currently Ethconnect functions in a single "nonce assigned at...

The changes in #175 should address these intermittent failures in the `events` and `subscriptions` tests 🤞 Or at the very least, we should get those merged and then revisit if...

Copying out a summary of the first error here - which was a timeout in `TestUpdateStreamInProgress`: ``` goroutine 538 [semacquire]: sync.runtime_SemacquireMutex(0xc000028334, 0x69a700, 0x1) /usr/local/go/src/runtime/sema.go:71 +0x47 sync.(*Mutex).lockSlow(0xc000028330) /usr/local/go/src/sync/mutex.go:138 +0x105 sync.(*Mutex).Lock(0xc000028330) /usr/local/go/src/sync/mutex.go:81...

Second error was an overrun of the background processing in one of the events test, beyond where the mocks had been cleaned up (a number of these were fixed in...

Updated title to be more specific, so we don't end up with a catch-all issue for all unit test failures

So there's a couple of considerations here: ## 1. Practical / code The Policy engine is responsible for updating the in-flight transactions, and it currently makes the assumption that it...

I think this actually caused the error, as it happened during processing of a `/spi/v1/reset` API call, which shouldn't have stopped the VM (but caused it to restart in place)

The line in question is: https://github.com/hyperledger/firefly/blob/75bb921d5747ad8a983b88864c891bf218987a72/internal/namespace/manager.go#L432

PR has been updated based on the conversation here, so that in the case a specific block number is supplied the recreated listener will still restart on the block before...

> we recreate a listener with block number of the last protocol ID but we haven't consumed all the events from that block could we lose those events? Is it...