This is a similar, but different bug from #1753.

Whenever the scanners finish fetching rows from HBase, they compact the cells and add the new points to a list. The list is not thread-safe, but accessed by multiple threads at a time. This can lead to concurrent modifications and inconsistent query results.

We observed unstable query results when OpenTSDB had to resolve many UIDs to their string values due to the use of regex filters (code starting here). Our query was looking at high-cardinality metrics, forcing it to resolve ~65000 UIDs.
On fresh/empty UID caches, these resolutions trigger the resolution and match callbacks asynchronously and from different threads, which means that processRow() is also called concurrently from the callback on different threads, modifying the non-thread-safe kvs list.

We were able to reliably reproduce the issue with queries for high-cardinality metrics. Symptoms include ConcurrentModificationExceptions and Found a key value item that was null in the logs.