Ack on messages with TCP/protobuf

EventStoreDB
#1

Hi there,

I am working on implementing persistent subscriptions feature for this package https://github.com/x-cubed/event-store-client. So far I’ve got everything working apart from acknowledging the messages.

I keep getting retries regardless of the message ack - which I am 90% sure is correct (sending event ids is not that difficult).

I am providing correct correlationId and correct subscription id (stream::group_name).

However, I just get retries all the time. Is there any way to see if ES actually acked the message?

Cheers

#2

Add a log here:
https://github.com/EventStore/EventStore/blob/release-v3.9.0/src/EventStore.Core/Services/PersistentSubscription/PersistentSubscriptionService.cs#L514

#3

btw a likely candidate might the uuid formatting (they are in a weird
wire format) see
https://github.com/gregoryyoung/libesclient/blob/master/src/wtf_uuid.c

#4

Would you mind explaining (only briefly) the way UUID is formatted?

#5

That code explains it (and its only for correlation id)

#6

Ah ok, so it doesn’t affect incoming event UUIDs for the ack command?

If so, that is already handled by the lib because I am able to write events.

Also running ES in docker, so would have hard time logging. Was hoping for an obvious mistake - will dig deeper.

Cheers

#7

I can assure you that acks work though (as the other clients all seem
to work :))

#8

For all future visitors to this post, the problem was indeed in the formatting of the UUID. Any UUID sent to ES via TCP/protobuf interface has to be converted to WTF UUD (love the naming) :slight_smile:

Simple example of conversion in JS:

var convertUuidToWtf = function(uuid) {
    var hex = uuid.replace(/-/g, '');
    var guid = hex.substring(6, 8) + hex.substring(4, 6) + hex.substring(2, 4) + hex.substring(0, 2) + "-" +
        hex.substring(10, 12) + hex.substring(8, 10) + "-" +
        hex.substring(14, 16) + hex.substring(12, 14) + "-" +
        hex.substring(16, 20) + "-" +
        hex.substring(20);
    return guid;
};

Example:

e048a9a2-4af2-4ee7-aaa2-fa9d83359127

becomes:

a2a948e0-f24a-e74e-aaa2-fa9d83359127

This is fairly hard to notice (at least for me) in any debugging output because I am quite used to scanning lots of data for just the end part of what I am looking for.

Thanks Greg Young for replies