Piotr Tabor

Hi Nick, Is there a repro using etcd client showing this problem? We rather assume callers responsibility to provide zap.NewNop(), rather making sure every log-line tests the logger for nullability.

> Hi! Yes, we had a problem where we had a panic. Was it `etcd` or the other customer of the library ? Could you, please, share a stack-trace when...

> I think if we want to push the responsibility to set the caller to always provide the logger, panic should always happen if logger is not provided. Agree. I...

> > I think if we want to push the responsibility to set the caller to always provide the logger, panic should always happen if logger is not provided. >...

> > @ahrtr @serathius Do you have opinion which of the pattern we should prefer. I would go for (2) unless the function is expected to be executed >O(100) times...

I'm targeting it here: https://etcd.io/docs/v3.4.0/dev-guide/. Also @nate-double-u is working on reorganization of the docs, so there will be a cleaner structure.

@embano1 the blog-post is awesome. Thank you.

> Yes, this case happens for readonly (not necessary to be serializable) transaction. But the [applyTxn](https://github.com/etcd-io/etcd/blob/fc690531e213d916e666d00fc072a30fbac86a0c/server/etcdserver/txn/txn.go#L314) is a generic implementation, and it doesn't know it's coming from readonly transaction. >...

+1. I see 3 options: a) **merkle tree should be integrated into bbolt**, i.e. we can reliably ask bbolt at each transactional state about it's checksum. This would guarantee bbolt...

@hexfusion: Could you, please, rebase or close this PR ? Trying to cleanup old PRs and PR backlog.