I don't think this catch logic is needed here? We can just let any exception bubble up here, because this logic is executed when each node receives a new cluster state and is processing the pipeline config.

problem is that clusterChanged(ClusterChangeEvent event) signature does not allow throwing exceptions.

originally it was being caught and threw a RuntimeException to get away with it

right, I see. It is just that the caller will never see this exception, the node processing this exception just won't ack the cluster state update.

Also the if there is an issue during pipeline creation the failure is likely to be caused in the put() method as we construct the pipeline to see if something is wrong before submitting a cluster state update. The only time I think we end up throwing an exception here if when an ingest plugin isn't installed on all nodes. Some nodes will fail the processor factory for a specific type. If this would happen then it isn't a good situation to be in, so we should think about how to best tackle this problem and I think we should open an issue for this.

Since we use Type.fromString only here maybe should change Type.fromString() so that it throws the right exception? We would have to change the signature to accept a tag.

I didn't feel good about doing that... but OK, I will :)

well it isn't very nice... but I think better than throwing an excepting and then one method higher up in the stack catching that exception and re-throwing it.