Seeing some oddities with events that are being delivered that appear to be wrong

So whilst trying track down a bug where not all events are making into my denormalized store, I came across this issue. Basically, the even data appears to be wrong:

This is what is being logged by my logger:

Could not deserialize event { EventType: “$>”, EventData: “0@Review-c684dfc0-c33e-830a-78ac-512702b4d410” }

This is how I’m logging it:

var asJson = Encoding.UTF8.GetString(resolvedEvent.Event.Data);
Logger.Error(“Could not deserialize event {@Event}”, this, new
EventData = asJson


where resolved event is the instance of EventStore.ClientAPI.ResolvedEvent being handed back to me by the Catchup subscription. This doesn’t look right to me and would explain why the deserialization failures.

When I look up this event in EventStore, nothing looks wrong to me


  "$type": "DAS.Services.Reviews.Messaging.EventStore.V1.Review.ReviewCreated, DAS.Services.Reviews.Messaging",
  "ClientId": "07468652-b8f0-dc0e-fae2-7c70efb51c2b",
  "ReviewSource": "Vendasta",
  "ReviewSite": "Facebook",
  "RatedComment": {
    "$type": "DAS.Services.Reviews.Messaging.EventStore.V1.Review.RatedCommentEventInfo, DAS.Services.Reviews.Messaging",
    "Rating": 4.0,
    "ParentReviewId": "00000000-0000-0000-0000-000000000000",
    "SourceReviewId": "RVW-EC1A5DB3CBAB4679A7F9418BDD4762D4",
    "CalculatedId": "c684dfc0-c33e-830a-78ac-512702b4d410",
    "Labels": {
      "$type": "System.String[], mscorlib",
      "$values": []
    "Author": "Bradley Gaarder",
    "Content": "",
    "CommentDate": "2016-01-06T21:37:41+00:00",
    "Comments": {
      "$type": "DAS.Services.Reviews.Messaging.EventStore.V1.Review.CommentEventInfo[], DAS.Services.Reviews.Messaging",
      "$values": []
  "EventType": "ReviewCreated",
  "Metadata": {
    "$type": "DAS.Infrastructure.Practices.EventSourcing.EventMetadata, DAS.Infrastructure.Practices",
    "AssemblyQualifiedType": "DAS.Services.Reviews.Messaging.EventStore.V1.Review.ReviewCreated, DAS.Services.Reviews.Messaging, Version=, Culture=neutral, PublicKeyToken=null",
    "EventNamespaces": "DAS.Services.Reviews.Review.ReviewCreated.V1"
  "EntityId": "c684dfc0-c33e-830a-78ac-512702b4d410",
  "EventId": "020d6256-3c1a-4eeb-ab6f-fcdaaf0a9cc3",
  "Version": 0,
  "Reason": null


  "$type": "DAS.Infrastructure.Practices.EventSourcing.EventMetadata, DAS.Infrastructure.Practices",
  "AssemblyQualifiedType": "DAS.Services.Reviews.Messaging.EventStore.V1.Review.ReviewCreated, DAS.Services.Reviews.Messaging, Version=, Culture=neutral, PublicKeyToken=null",
  "EventNamespaces": "DAS.Services.Reviews.Review.ReviewCreated.V1"

Any ideas?

Also, this is how the sub is being set up. Default values at the moment:

public void CatchUpSubscription(
string streamName,
int lastSeenIndex,
Action<EventInfo, int> processAction,
int liveQueueSize = 10000,
int readBatchSize = 500,
bool resolveLinkTos = false)
_processAction = processAction;

int? startIndex = lastSeenIndex;
if (lastSeenIndex == -2)
startIndex = null;

Logger.Verbose($“Subscribing to {streamName} as catch-up subscription at index {lastSeenIndex}…”, this);
var settings = new CatchUpSubscriptionSettings(liveQueueSize, readBatchSize, false, resolveLinkTos);
var sub = _eventStore.SubscribeToStreamFrom(

_disposableActionCollection.Add(() => sub.Stop());


The events that are failing deserialisation are unresolved LinkTo events, you can tell this by the event type of “$>”. The data of these events are not json, but rather a string of “{eventNumber}@{streamId}”.

If you read a LinkTo event with resolveLinkTos set to true, Event Store will send you the event that the linkTo points to. Otherwise, you will get the linkTo event itself.

Since an Event Store read normally has resolveLinkTos set to true and your subscription has this set to false, that would explain the difference you are seeing between a single read and the subscription.

There is an IsResolved property on the event that tells you whether an event is a normal resolved event or a linkTo event. You could use this to filter these events out.

Otherwise, you could set resolveLinkTos to true.

Oh crap! That did get changed from true to false. Thank you so much