The stream <streamname> managed by projection <n> has been written to from the outside.

We are receiving the following error form our projection:

The stream managed by projection has been written to from the outside.

We initially create a stream from outside the Projection (we have tried it via the .NET driver and Postman) then start out projection which us filtered to a specific Category and Event Type.

After an event is received, we try the following:

emit(dailyStream, “TillTransactionStartedEvent”, new TillTransactionStartedEvent(e), new MetaData());

It’s at this stage we get this error.

We have tried various combinations of parameters in emit in case we had made a mistake, but we keep getting the same error message.

The same projection works fine if we let it create the stream, so we hope our javascript isn’t the source of the problem.

Anyone help?

yeah, you can’t do that.

only the projection that creates the stream is allowed to write to it, and projections are only allowed to write to streams they created.

You cannot write to a stream and then let the projection write to the stream too.

The reason is, when a projection links/emits events to a stream, it will write some metadata as part of the event that identifies the projection as well other bits of interesting information. This metadata is read and then used to validate a couple of things, one of them being that the same projection that wrote to the stream previously is the one that is about to do the same.

Thanks for the quick reply.

At least we know we can’t do that now.

Any tips about how to recover from this? Happened to manually emit an event on a system managed projection ($by_event_type) which now fails.

Could you try skipping the projection forward by one event (via the checkpoint)?

@steven.blair First, thanks for the response.

I assume that means emitting a new checkpoint event with an updated position. It seems that the checkpoint stream should be $projections-$by_event_type-checkpoint. How to figure out what the position would have to be?

The error being displayed should hopefulyl tell you the position of the problem? You could simply skip past it by creating the new checkpoint event.

@steven.blair Thanks again.

The error does not state anything about the position:

The given checkpoint is invalid. Possible causes might include having written an event to the projection’s managed stream. The bad checkpoint: Phase: 0

How about the checkpoint stream. Is it $projections-$by_event_type-checkpoint ?

Yeah, you could simply skip past the problem (if that’s an option for you)

This option would be perfect, however, I don’t understand how to do it. I get the conceptual part of emitting a new checkpoint event and skipping the event, but how to do it practically?

  • What’s the checkpoint stream?
  • How to identify the position at which the projection has stopped (I would expect to find this in the last checkpoint event but it seems that not the case since the projection is not configured to emit a checkpoint event at intervals)?
  • How to identify what is the position of the event after the faulty one?

I’ve read through the documentation on but couldn’t find details about these topics.

I would really appreciate some guides in regards to the above questions. Thanks!

If you want to push the checpoint forward, there are a couple of approaches I know of.
The easiest, os simply from the UI browse to the checkpoint stream.
Click one of the checpoint events, and at the top right, click “Add New Like This”
Simply add in your event and post it.

as for your other question regarding identifying where the problem has occured, can you try browsing to the projection, and hit Debug from the UI. It should break out on the event causing the problem and let you know the position.

Just leaving an update for future reference.

I’ve tried navigating with the debugger through the events but due to the volume of events, it was not feasible. Having seen the endpoint being called by the web client (/projections/read-events), I’ve scripted the loading assuming I would find the position of the faulty event. The event did not appear in the list (probably because it was emitted to a target stream of the $by_event_type projection leading by it not being picked up), so I couldn’t determine the where to move the checkpoint.

I ended up resetting the projection after making sure no client will be negatively affected by this.

Thanks for the help!