Hello all, I wanted to ask if there's additional information in regards to how K3S sees the Kine tables for MariaDB. I've ran into a situation in which my entire cluster is offline as the datastore seems...corrupted? Yet it looks okay on my end. This started a couple days ago when I had taken both cluster servers offline, Alpha and Bravo. This was due to I needed to ensure that the kine table was no longer in use so I could dump it and drop it (as I was moving this from a stand-alone database server to a two-node replication server, at least for now). I dumped the data twice (just in case, i've had weird stuff happen before), and then I dropped the schema. From there, I setup replication between the two nodes, verified replication works, and then re-imported the schema + kine table. This is where the issues started. (oop didnt mean to send already) Now, upon startup of either cluster server, I continuously get "unexpected EOF" in the logs. For example:

I0812 22:03:25.243037   25905 reflector.go:257] Listing and watching *admissionregistration.MutatingWebhookConfiguration from storage/cacher.go:/mutatingwebhookconfigurations
I0812 22:03:25.245316   25905 reflector.go:257] Listing and watching *apps.StatefulSet from storage/cacher.go:/statefulsets
W0812 22:03:25.245835   25905 reflector.go:424] storage/cacher.go:/mutatingwebhookconfigurations: failed to list *admissionregistration.MutatingWebhookConfiguration: unexpected EOF
E0812 22:03:25.245857   25905 cacher.go:440] cacher (*admissionregistration.MutatingWebhookConfiguration): unexpected ListAndWatch error: failed to list *admissionregistration.MutatingWebhookConfiguration: unexpected EOF; reinitializing..

I'm unsure as to what this may be about. I've started K3S with --debug -v 5 (couldn't find the maximum value so 5 was just thrown out there) with no luck. These errors in specific seem to point to the apiserver responding with the unexpected EOF error, but I am at a loss past that. I see the kine table, the keys, columns, indexes, all of it right there. Just seems that there's either a row or some sort of element inside the data itself causing K3S to fail. If needed, these members were both running fine before this and are on version v1.25.15+k3s2.