Can someone please confirm expected output from logcat on volume button hardkey press and release?

I have a stock OnePlus 8T+ 5G TMO that has been displaying very strange behavior. It would ask if I want to boot into safe-mode every time I try to power down or restart, and sometimes it would continuously flash on then go dark again after going to lock screen, as if the power key were being continuously spammed. Eventually, I realized it was behaving as if the volume up key were "stuck". This is strange, because the hard key itself is very clearly giving mechanical feedback on both actuation and then release. Nonetheless, I thoroughly cleaned the whole phone with a liberal amount of 99% isopropyl (after powering down from the recovery menu), and then was successfully able to power back on and have normal operation again. However, I did notice the volume keys were still behaving a bit strangely; to begin with, I only confirmed it was stuck in a "down" state at all because after booting into the recovery menu, it immediately began to rapidly cycle through the menu choices as if the button were held down. Pressing down on any key (including itself) would pause the cycling, but letting go would immediately resume it. After the cleaning, it would have practically no delay on input nor repeat delay, almost like it had "Turbo Mode" turned on like on the old-school modded controllers. Since it's at least in a usable state now, I enable ADB and hop on my Chromebook to take a look at logcat. So what I'm seeing is that each individual key press is getting logged as four lines: > \# adb -d shell logcat > --------- beginning of main > 08-18 21:46:14.770 1176 2717 D APM_AudioPolicyManager: setVolumeCurveIndex device 00000002, index 1 > 08-18 21:46:14.774 1176 1780 D APM_AudioPolicyManager: setVolumeCurveIndex device 00000002, index 1 > 08-18 21:46:14.775 1176 1780 D APM_AudioPolicyManager: setVolumeCurveIndex device 00000002, index 1 > 08-18 21:46:14.775 1176 1780 D APM_AudioPolicyManager: setVolumeCurveIndex device 00000002, index 1 Unfortunately, I'm not too familiar with troubleshooting hardkeys, so I'm actually not too sure whether this behavior is expected or not?