strange naming issue when storing event

I know this sounds crazy and like it’s some stupid coding error of mine, but please take a look
when I start with a brand new database and persist an event which has a structure of






the event in the atomviewer looks like this

0 CommandDispatch ContactVendorForBrideCmd 2014-10-06 17:01



“MailInterceptorId”: “ded945d8-73b0-4084-aef1-8dadeed42cc2”,

“ProfileDetailsDtoDto”: {

“ProfileId”: “2bf5cc2d-d9fc-46a1-8060-0ca68a6bf6a7”,

“Email”: “”,

“Name”: “Raif the great”,

“DisplayName”: “Raif the most exalted one”


the second time I post the event it looks like this

2014-10-06 17:27

  "MailInterceptorId": "5f9d0302-1b60-47df-9a2d-e22564de0869",
  "ProfileDetailsDto": {
    "ProfileId": "a6196ec7-6201-4866-8036-affeb5ee3627",
    "Email": "",
    "Name": "Raif the great",
    "DisplayName": "Raif the most exalted one"

As you can see the Dto suffix is duplicated in the first one and not in the second one

I have inspected the data all the way up to just before I push it the GES via AppendToStreamAsyc in the .net api and it does not have the double dto. So that’s after jsonserialization, and after encode with utf8 it’s still in the proper state but after it posts to Eventstore it’s different.

I can delete the db and replay the experience every time.

If anyone know what I’m doing wrong that would be great. Seems very strange to me.



We never look at your data (its a vector of byte in and out)

send over a repro and I would be happy to try it

Sorry to be thick, but what exactly would you need? my whole test project, a zip of the db. What’s the best thing for me to do?

Anything that can reproduce the issue off a blank database.

We don’t even deserialize your data on our side over the protobufs api it is always kept as a vector of bytes never as an object

Hi, so here is a git repo

if you pull that and build the sln it should download some nuget then compile.

I start the db using this line

EventStore.ClusterNode.exe --db .\db

if you just run the console app you’ll see it pushes an event.

If you look at Infrastructure.MessageBinderBase.PostEvent, this is where it does the push.

I’m sure it’s either something in my environment or something stupid I"m doing, but I can’t see what. If that’s the case I’m very sorry to waste your time.


Could you cut it down to a MINIMAL sample that shows the same issue? For avoidance of doubt, a minimal repro should likely be a single .cs file, with no dependencies on StructureMap etc…

Yes I can do that, it’ll take me a bit.


Ok not surprisingly that changes things a bit.
I have stripped it down, which included stripping down the actual event content.

Now I delete the db and the db-logs folders.

I restart the db and there are none of my events in it.

I run my stripped down one file long test and an event is posted.

I look at the event and it’s the same event as before. All the sup objects and everything.

So something is getting cached in or something.

if you check

you’ll see the new test


Maybe you can share your command line and command lines from your console?

the console app merely has to run it’s all in the program main.

the db is started by calling

$ EventStore.ClusterNode.exe --db .\db

I mean how did you ‘delete’ you db if it comes back.

Can you do a delete command line with a ls that shows there is nothing there and restart?

We have never had anyone have an issue with events magically appearing in a fresh database.

This is very embarrassing as you can imagine.

so I have been using windows explorer to delete those files, actually called .partners and .partners-logs.

so I did an ls in console and I don’t see those files, but in windows explorer I do. Perhaps it has something to do with the leading . but usually it’s windows that screws you with those.

But when i delete those files in WE and I refresh the atom ui it’s a fresh db, none of my events in it.

I mean I’m sure this is not a GES issue, but rather some kind of demonic possession.



so obviously I need the -a. but I’ve been doing
rm -r .partners

rm -r .partners-logs

then ls, it’s gone.

restart with different name.

try again. same result




I forgot to reply all. doh, so these are a bit late. sorry

Did you remember to clear your browser cache as well?

ok public disclosure, the browser was caching the views in the Atom UI.

In my defense I vigorously ctl f5’d as well as closing all instances of the browser and restarting.

The TAKE AWAY is that the cache for this app is very hardy and you must manually clear cache from the settings if you run into this.



What browser were you using? Neither Chrome or Safari seem to exhibit this behaviour for me?


It was chrome, on windows.

@james I have seen this behavior with restarting as the individual event is set with a cache on it. Since the restart of the db has the same stream ids etc it gets the old cached event. We could add a cache busting id for our ui but this is intended behavior as it should be cacheable