Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Subscription status remains the same for very busy addresses #566
While researching something for issue #348 I discovered this probably rare bug.
When an address contains too many transactions, the subscription status stops changing on newer transactions.
This threshold depends on the MAX_SEND env variable and in default installation is 10309 transactions. When setting the minimum MAX_SEND = 350000 the limit is 3608 transactions.
An easy way to try it is in regtest by mining to a single address with the
The reason this happens is that session's
Initially I thought about using the reverse order of the limited history to guarantee that the status will always change but then we will hit the
Do think it makes sense to return an error message when the limit is reached?