Vlad

>IMO, it could also be important to allow users some control over retries. If we are not sure what they want, we should also allow users to completely control the...

We are currently in last stage of development of new sampling protocol(Shwap). And after it is realeased this issue will no longer will be relevant.

The code that uses Bitswap will be completely different and might not trigger such a condition. Therefore, we should wait for the same report to occur after Shwap is released...

Metrics are indicating blacklisting events happen, even when real blacklisting is skipped. It is done for monitoring purposes, to allow safe investigation of blacklisting.

Hm, so it is probably metric or dashboard naming issue. The metric is supposed shows amount of blacklisting events being triggered, rather then amount of actually blacklisted peers.

One suggestion for resolving this issue and https://github.com/celestiaorg/celestia-node/issues/2702 would be to create subcomponent dedicated for blacklisting from all of our components. It will allow us to create metrics for amount...

~~Does it constantly crash or it was a single event?~~ Nvm, found the answer

The problem arises from the badger-db internal allocator, which failed to acquire memory. One possible reason for this issue could be that the store was initialized with a larger Memtable...

Additional info from report: ``` the bootstrapper WS TLS setup didn't change and the cert is still valid ```

Additionally, we have shrexSub, that also monitors amount of full nodes within active connections. Mainnet metrics for 3 nodes suggests that there are 100+ FN connected for each reporting node.