The issue is due to a race condition between bucket clean-up and stream repair. If bucket clean-up happens while stream repair is in progress, it will clean-up all the book keeping related to the bucket in stream-state. When repair stream code path tries to access the book-keeping, it results in a panic.
The issue could be reproduced using the following steps:
a. Add a sleep of 30 seconds in sendRestartMsg, at KV_SENDER_RESTART_VBUCKETS_RESPONSE after needsRollback call
b. Add a sleep in indexer for 30 seconds at removeIndexesFromStream after sending the message to timekeeper
c. Cluster run with 1KV+n1ql, 1KV+index, 1 index node
d. Create and build an index on one indexer ndoe
e. After the index is created, remove the indexer node on which the index was built. Trigger rebalance. Rebalance will move the index to the other node and clean-up the bucket from stream
f. Rebalance should fail and indexer should panic
The for indexer panic is because, the stream status is validated only once while processing the KV_SENDER_RESTART_VBUCKETS_RESPONSE. After the status is validated and if stream clean-up happens, updateRepairState method would panic as the stream is cleaned up. We are locking around the stream state variables twice but validating the status only once.