WarpStream relies on a proprietary metadata store hosted within their internal network to operate, so it's pretty unlikely that Jepsen tests could cover that.
If you're ok with the externally hosted metadata stores as well as the high per-request latencies (p99 of 400ms, according to WarpStream), it's highly likely that things like liveness and safety properties are pretty far from your mind. So, I wouldn't bank on them submitting to a Jepsen test. :)
I think that WarpStream relying on a proprietary metadata store isn't an issue for Jepsen tests. If I understand correctly, Jepsen tests treat the distributed databases (or logs like Kafka) pretty much as a black box. Jepsen tests introduce partitions and look for missing/unexpected items against the items that were acknowledged as written successfully by the system.
If you look at Kyle's blog post, https://aphyr.com/posts/293-jepsen-kafka, there is no mention of looking into a broker's storage or any storage for that matter.
FWIW we subject WarpStream to continuous chaos/fault injection in our integration tests and staging environment to verify correctness and liveness properties. I wouldn't say they're far from our mind, we've just made a big trade off around latency that we think will make sense for a lot of people.
