Skip deleted events instead of crashing

[norpan]

I tried to delete an event stream. The $ce-x subscription still provides the event but with the following:

16:18:55.528 [debug] Persistent subscription "$ce-x::X" event appeared: %Extreme.Msg.PersistentSubscriptionStreamEventAppeared{event: %Extreme.Msg.ResolvedIndexedEvent{event: %Extreme.Msg.EventRecord{created: nil, created_epoch: nil, data: nil, data_content_type: nil, event_id: nil, event_number: nil, event_stream_id: nil, event_type: nil, metadata: nil, metadata_content_type: nil}, link: %Extreme.Msg.EventRecord{...

As opposed to a non-deleted stream event that gives:

16:18:55.515 [debug] Persistent subscription "$ce-x::X" event appeared: %Extreme.Msg.PersistentSubscriptionStreamEventAppeared{event: %Extreme.Msg.ResolvedIndexedEvent{event: %Extreme.Msg.EventRecord{created: 636838691641959360, created_epoch: 1548272364195, data: "...

This makes the code crash:

16:18:55.538 [error] GenServer {Commanded.EventStore.Adapters.Extreme.Subscription, "$ce-x", "X"} terminating
** (FunctionClauseError) no function clause matching in String.Unicode.next_grapheme_size/1
    (elixir) lib/elixir/unicode/unicode.ex:40: String.Unicode.next_grapheme_size(nil)
    (elixir) lib/string.ex:1693: String.first/1
    (commanded_extreme_adapter) lib/extreme/subscription.ex:104: Commanded.EventStore.Adapters.Extreme.Subscription.handle_info/2
    (stdlib) gen_server.erl:637: :gen_server.try_dispatch/4
    (stdlib) gen_server.erl:711: :gen_server.handle_msg/6
    (stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3

since event_type is nil there.

I added a check to skip these deleted events instead of crashing.

[slashdotdash]

Thanks for the fix @norpan.

[losttime]

I'm getting this same error in a new project when the a message is being sent to an event handler. There are no deleted messages involved (standing up fresh Event Store with docker). Could something else be causing my event_type to be nil?

[slashdotdash]

@losttime Do you have other services using the Event Store?

This PR hasn't yet been published to Hex, I will create a new release now.

[slashdotdash]

Published to Hex as v0.7.0.

[losttime]

With the head of master (or 0.7.0 now I presume) I'm able to get around the error, but the event isn't making it to my handle/2 function in my Event Handler because the event_type is nil.

I've got an Aggregate set up, and it's processing the event to update its internal state just fine, but the separate Event Handler in a separate app in my umbrella isn't getting the event. Those are the only 2 things making use of the Event Store.

I'm going to look dig in a bit to try to figure out why the event's event_type is nil.

[losttime]

It looks like the issue I have been seeing was due to a PersistentSubscriptionStreamEventAppeared event, which appear to precede the actual event that was pushed to the event store. This is its structure:

%Extreme.Msg.PersistentSubscriptionStreamEventAppeared{
  event: %Extreme.Msg.ResolvedIndexedEvent{
    event: %Extreme.Msg.EventRecord{
      created: nil,
      created_epoch: nil,
      data: nil,
      data_content_type: nil,
      event_id: nil,
      event_number: nil,
      event_stream_id: nil,
      event_type: nil,
      metadata: nil,
      metadata_content_type: nil
    },
    link: %Extreme.Msg.EventRecord{
      created: 636870597207254030,
      created_epoch: 1551462920725,
      data: "0@commandeddev-fooc@example.com",
      data_content_type: 0,
      event_id: <<75, 156, 33, 141, 245, 129, 59, 71, 190, 19, 128, 175, 213,
        218, 23, 217>>,
      event_number: 2,
      event_stream_id: "$ce-commandeddev",
      event_type: "$>",
      metadata: "{\"$v\":\"3:-1:1:3\",\"$c\":836180,\"$p\":836180,\"$o\":\"commandeddev-fooc@example.com\",\"$causedBy\":\"285d1ade-dfbd-044f-b202-ff08b6b47b17\"}",
      metadata_content_type: 0
    }
  }
}

I presume this event is fine.

I guess my real problem is that my actual event isn't getting delivered to my handler, which is different than what was talked about in the PR, so I'll take it elsewhere (continued on #24 ).