core/chains/evm/logpoller: fix doc formatting

core/chains/evm/logpoller/doc.go

@@ -3,18 +3,18 @@
 // It can be thought of as a more performant and sophisticated version
 // of eth_getLogs https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getlogs.
 // Having a local table of relevant, continually canonical logs allows us to 2 main advantages:
-// - Have hundreds of jobs/clients querying for logs without overloading the underlying RPC provider.
-// - Do more sophisticated querying (filter by confirmations/time/log contents, efficiently join between the logs table
-// and other tables on the node, etc.)
+//   - Have hundreds of jobs/clients querying for logs without overloading the underlying RPC provider.
+//   - Do more sophisticated querying (filter by confirmations/time/log contents, efficiently join between the logs table
+//     and other tables on the node, etc.)
 //
 // Guarantees provided by the poller:
-// - Queries always return the logs from the _current_ canonical chain (same as eth_getLogs). In particular
-// that means that querying unfinalized logs may change between queries but finalized logs remain stable.
-// The threshold between unfinalized and finalized logs is the finalityDepth parameter, chosen such that with
-// exceedingly high probability logs finalityDepth deep cannot be reorged.
-// - After calling RegisterFilter with a particular event, it will never miss logs for that event
-// despite node crashes and reorgs. The granularity of the filter is always at least one block (more when backfilling).
-// - After calling Replay(fromBlock), all blocks including that one to the latest chain tip will be polled
-// with the current filter. This can be used on first time job add to specify a start block from which you wish to capture
-// existing logs.
+//   - Queries always return the logs from the _current_ canonical chain (same as eth_getLogs). In particular
+//     that means that querying unfinalized logs may change between queries but finalized logs remain stable.
+//     The threshold between unfinalized and finalized logs is the finalityDepth parameter, chosen such that with
+//     exceedingly high probability logs finalityDepth deep cannot be reorged.
+//   - After calling RegisterFilter with a particular event, it will never miss logs for that event
+//     despite node crashes and reorgs. The granularity of the filter is always at least one block (more when backfilling).
+//   - After calling Replay(fromBlock), all blocks including that one to the latest chain tip will be polled
+//     with the current filter. This can be used on first time job add to specify a start block from which you wish to capture
+//     existing logs.
 package logpoller

core/chains/evm/logpoller/log_poller.go

@@ -97,10 +97,11 @@ type ReplayRequest struct {
 // NewLogPoller creates a log poller. Note there is an assumption
 // that blocks can be processed faster than they are produced for the given chain, or the poller will fall behind.
 // Block processing involves the following calls in steady state (without reorgs):
-// - eth_getBlockByNumber - headers only (transaction hashes, not full transaction objects),
-// - eth_getLogs - get the logs for the block
-// - 1 db read latest block - for checking reorgs
-// - 1 db tx including block write and logs write to logs.
+//   - eth_getBlockByNumber - headers only (transaction hashes, not full transaction objects),
+//   - eth_getLogs - get the logs for the block
+//   - 1 db read latest block - for checking reorgs
+//   - 1 db tx including block write and logs write to logs.
+//
 // How fast that can be done depends largely on network speed and DB, but even for the fastest
 // support chain, polygon, which has 2s block times, we need RPCs roughly with <= 500ms latency
 func NewLogPoller(orm *ORM, ec Client, lggr logger.Logger, pollPeriod time.Duration,
@@ -179,8 +180,10 @@ func (filter *Filter) contains(other *Filter) bool {
 // the log poller will pick those up and save them. For topic specific queries see content based querying.
 // Clients may choose to MergeFilter and then Replay in order to ensure desired logs are present.
 // NOTE: due to constraints of the eth filter, there is "leakage" between successive MergeFilter calls, for example
-// RegisterFilter(event1, addr1)
-// RegisterFilter(event2, addr2)
+//
+//	RegisterFilter(event1, addr1)
+//	RegisterFilter(event2, addr2)
+//
 // will result in the poller saving (event1, addr2) or (event2, addr1) as well, should it exist.
 // Generally speaking this is harmless. We enforce that EventSigs and Addresses are non-empty,
 // which means that anonymous events are not supported and log.Topics >= 1 always (log.Topics[0] is the event signature).