Sonar detects that in this Spliterator we have the volatile field that we are modifying non-atomically:

    private static class AckFrameSpliterator implements Spliterator.OfLong {
        ...
        private volatile long largest;
        private volatile long smallest;
        private volatile long pn; // the current packet number

        // The stream returns packet number in decreasing order
        // (largest packet number is returned first)
        private boolean ackAndDecId(LongConsumer action) {
            assert ackFrame.isAcknowledging(pn)
                    : "%s is not acknowledging %s".formatted(ackFrame, pn);
            action.accept(pn--); // <----- HERE
            return true;
        }


Given that Spliterators are not expected to be thread-safe, maybe the real question is why these fields are volatiles?