idempotency

Starting with:

curl -i -H “Accept:application/json” “http://192.168.59.103:2113/streams/mats2

I get an expected 404.

Then I have file, with the following contents

[{

"eventId": "fbf4a1a1-b4a3-4dfe-a01f-ec52c34e16e4",

"eventType": "event-type",

"data": { "a": "1" }

}]

  1. curl -i -d @simplest-event.txthttp://192.168.59.103:2113/streams/mats2” -H “Content-Type:application/vnd.eventstore.events+json”
    I get an expected 201 Created

  2. curl -i -d @simplest-event.txthttp://192.168.59.103:2113/streams/mats2” -H “Content-Type:application/vnd.eventstore.events+json”
    I get an expected 201 Created

  3. curl -i -H “Accept:application/json” “http://192.168.59.103:2113/streams/mats2

I get an expected 200 OK, but I see two events with the same eventId. The documentation mentions “if you edit the Message ID GUID and post it again it will append to the stream”, so my expectation is that it would be idempotent if I don’t. Am I missing something?

Hi Mats

I have just followed the same process that you did on an empty Event Store (version 3.0.1 Mac just downloaded from the geteventstore.com website) and I receive the following output from step 4:

HTTP/1.1 200 OK

Access-Control-Allow-Methods: POST, DELETE, GET, OPTIONS

Access-Control-Allow-Headers: Content-Type, X-Requested-With, X-PINGOTHER, Authorization, ES-LongPoll, ES-ExpectedVersion, ES-EventId, ES-EventType, ES-RequiresMaster, ES-HardDelete, ES-ResolveLinkTo, ES-ExpectedVersion

Access-Control-Allow-Origin: *

Access-Control-Expose-Headers: Location, ES-Position

Cache-Control: max-age=0, no-cache, must-revalidate

Vary: Accept

ETag: “0;-43840953”

Content-Type: application/json; charset=utf-8

Server: Mono-HTTPAPI/1.0

Content-Length: 1210

Keep-Alive: timeout=15,max=100

{

“title”: “Event stream ‘mats2’”,

“id”: “http://127.0.0.1:2113/streams/mats2”,

“updated”: “2015-01-28T15:36:46.20048Z”,

“streamId”: “mats2”,

“author”: {

"name": "EventStore"

},

“headOfStream”: true,

“selfUrl”: “http://127.0.0.1:2113/streams/mats2”,

“eTag”: “0;248368668”,

“links”: [

{

  "uri": "http://127.0.0.1:2113/streams/mats2",

  "relation": "self"

},

{

  "uri": "http://127.0.0.1:2113/streams/mats2/head/backward/20",

  "relation": "first"

},

{

  "uri": "http://127.0.0.1:2113/streams/mats2/1/forward/20",

  "relation": "previous"

},

{

  "uri": "http://127.0.0.1:2113/streams/mats2/metadata",

  "relation": "metadata"

}

],

“entries”: [

{

  "title": "0@mats2",

  "id": "http://127.0.0.1:2113/streams/mats2/0",

  "updated": "2015-01-28T15:36:46.20048Z",

  "author": {

    "name": "EventStore"

  },

  "summary": "event-type",

  "links": [

    {

      "uri": "http://127.0.0.1:2113/streams/mats2/0",

      "relation": "edit"

    },

    {

      "uri": "http://127.0.0.1:2113/streams/mats2/0",

      "relation": "alternate"

    }

  ]

}

]

}

Which appears to be the correct behaviour (only 1 event), I have also verified in the WebUI that only one event is in the stream.

Which version of the server were you using? If you weren’t using 3.0.1 can you try again with 3.0.1 and let us know how you get on.

Jon

Where are you specifying the expected version header? Idempotency is only guaranteed if you use ES-ExpectedVersion + the same event ids.

yes, you are right I did do something with the ES-ExpectedVersion. But on a different stream. Using curl.

I am running GES (3.0.1) as a docker container https://registry.hub.docker.com/u/bvaauctions/event-store/.

If I start up the eventstore and do a few:

curl -d @simplest-event.txthttp://192.168.59.103:2113/streams/mats1” -H “Content-Type:application/vnd.eventstore.events+json”

it will work as expected, I see only one event

Then:

curl -d @simplest-event.txthttp://192.168.59.103:2113/streams/mats1” -H “Content-Type:application/vnd.eventstore.events+json” -H “ES-ExpectedVersion:4”

Also, no event created

Then follow up with a few writes to a different stream:

curl -d @simplest-event.txthttp://192.168.59.103:2113/streams/mats2” -H “Content-Type:application/vnd.eventstore.events+json”

It creates new events on each write. I wouldn’t quite have expected this behavior when writing to a different stream.