hubcio commented on issue #4066: URL: https://github.com/apache/iggy/issues/4066#issuecomment-5551342852
AFAIR message_id is not used on server side at all. they don't need to be crypto-secure. since the server-ng promotion the server never reads the message id at all. it stores the frame verbatim (the per-message checksum covers the id, which is why the sdks mint it instead of the server) and hands it back on poll. the old server-side dedup that keyed on it is gone, write dedup is now keyed on the vsr client id plus request number. the one place that still cares is connectors. a few sinks use the id as a stable key, e.g. the mongodb sink builds `stream:topic:partition:message_id` as `_id` and treats a duplicate key as a replay, so the second doc is silently dropped. ids have to stay unique within a partition across all producers. secrecy is irrelevant. that rules out plain sequential ids as a default (two producers on one partition would collide) and makes snowflake awkward, since the sdk has no node id to put in it. a non-crypto prng filling 16 bytes is fine, uuidv4 (v7 is too slow) is fine too. for node i'd start with the string to bigint to buffer round trip, that's most of the cost, not the rng. happy to review a pr along those lines. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
