Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @nvanbenschoten and @shralex)

-- commits line 5 at r1:
Do we have a theory about why a sequence number might be missing or duplicated for operations in a batch. Request sequence numbers are assigned by the txnSeqNumAllocator. Are there flaws in its sequence number allocation logic?

-- commits line 7 at r1:

and adds more information in case the panic still occurs.

It doesn't look like we've added any new information to the panic. This seems like a good idea to help us understand the failure mode better, if we ever see it again.

Reviewed 2 of 2 files at r2, all commit messages.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @shralex)

pkg/roachpb/batch.go line 379 at r2 (raw file):

		}
	}
	panic(fmt.Errorf("unreachable. Batch requests: %s", ba.Requests))

nit: fmt.Sprintf should be sufficient here.

pkg/roachpb/batch.go line 379 at r2 (raw file):

		}
	}
	panic(fmt.Errorf("unreachable. Batch requests: %s", ba.Requests))

Does the string format of []RequestUnion print the sequence number of each request? Let's make sure we put enough information in here so that we can have a good chance of diagnosing the issue next time this happens.

Done

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @nvanbenschoten)

-- commits line 5 at r1:

Added all we know to the PR description

-- commits line 7 at r1:

Added

pkg/roachpb/batch.go line 379 at r2 (raw file):

Done

pkg/roachpb/batch.go line 379 at r2 (raw file):

You were right. Changed this, now if the test does "{[]Request{withSeq(put, 1), withSeq(etC, -1)}, true}," it will print:
panic: unreachable. Batch requests: put:<header:<sequence:1 > value:<timestamp:<> > > ,end_txn:<header:<sequence:-1 > commit:true >

Reviewed 1 of 1 files at r3, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @shralex)

pkg/roachpb/batch.go line 379 at r3 (raw file):

		}
	}
	// Unreachable

nit: Missing punctuation on this comment. // Unreachable.

pkg/roachpb/batch.go line 383 at r3 (raw file):

	for i, args := range ba.Requests {
		sb.WriteString(args.String())
		if i < len(ba.Requests) - 1 {

nit: moving this up and making the check if i > 0 { may be slightly easier to reason about.