-
UUID
00000000-0000-0000-0000-000000000000
is invalid UUID type 4 from spec perspective. Kafka protocol says UUID is type 4 UUID - so to pass this UUID type 4 invariants (type, version) has to be bent. -
Using byte 0xFF to represent null Cursor was new for me - I understand that this can be done because var int could not start with 0xFF - it would be worth to explain with reference to kafka docs - do they really use this shortcut - where, why?
The Kafka doc doesn’t say that the Cursor can be nulled using 0xFF, I (believe) this can be the case when the topic is unknown and thus there’s no partition to retrieve. Hence there’s no cursor information for this “non-existent” partition/topic.
Binspec can be useful to show you what the Kafka doc doesn’t explicitly list: https://binspec.org/
This website UUID / GUID Validator Online suggests that you’re right about the UUID, 0000000-0000-0000-0000-000000000000
is apparently not a valid UUID.
But maybe we’re passed with an invalid UUID because the challenge #vt6 is requesting for an “unknown” topic, maybe that’s why?..
@izderadicka Thanks for the comments!
-
You’re absolutely right—it’s not a valid UUID. That’s precisely why it’s used in the response to signal the
UNKNOWN_TOPIC_OR_PARTITION
error, much like how -1 often indicates NOT_FOUND in index() functions for strings in many languages. -
Yep,
0xFF
represents -1 or null. Unfortunately there’re no official docs that can be referenced.
The author of this challenge, @ryan-gang, spent countless hours reverse-engineering Kafka and digging through its source code.
Here’s the relevant JSON file in the source code:
These JSON files contain the entire schema of a request / response, and the parser + serializer + documentation are auto generated from them.