Can source bucket for one Eventing Function be target for another Eventing Function

I have two buckets called X and Y. Documents in each bucket have a type field.

I have set up the eventing service so that when documents in bucket X are updated I generate an update document in bucket Y.

I’m now trying to create another function so that when these update documents are added to Y I update the value of a document in bucket X (not the one that caused the initial event). However, this second function doesn’t seem to work. I’m wondering whether the problem is that by making bucket X the source for the first function it can no longer work as the target of the second function.

I’ve already spent some time trying to debug but haven’t had much luck. Is what I’m trying to do actually possible?

The functions filter on the ‘type’ attribute so there’s no way of triggering a circular update loop.

Any guidance would be appreciated.

Editing my earlier response: please see the below reason of why it wouldn’t work.

@venkat thanks for your response. Is there any timeframe around the GA release?

@andrew1 : For now, we do not support or recommend the scenario you mentioned. Circular mutations will lead to many issues(cascading of function invocations) and we do not recommend it. Can you explain a little more on how this scenario exists in your design? Or do you see any possible workarounds.

In my application I have a lesson document that contains an array of items. When the lesson is saved I want to update the states of all the items in the lesson.

In a highly simplified form say I have:
lesson:100 {
type: lesson,
items: [item:1, item:2, item:3].
updated_on: 1234
}

item:1 {
type: item,
updated_on
},
etc

When I save the lesson document I want to update all the item documents with the updated_on field from the lesson.

I would like to keep lesson and item documents in the same bucket to avoid multiple buckets on the server and having to run multiple replication processes on the client.

Ability to update source bucket is not available for now, and is high on our roadmap. Once we have that feature, am sure you can do this in the same bucket - a.k.a content enrichment :slight_smile:

Thanks for this thread and the feedback.

Thanks Venkat,
That would indeed be a great feature.

Not being able to edit documents in the source bucket (or add new ones) really reduces the usefulness of the Eventing service for now.

Any timeframe on the GA release for the Eventing Service?

Managing recursive mutations is a tricky business and hence we did not allow it in the V1 of the product. But this is being targeted to be addressed soon.

As you know it is in Beta now, and we are looking at Summer for GA.

Seems this change is tracked by https://issues.couchbase.com/browse/MB-27268.
So such modifications to source bucket will still generate DCP mutations ?
Will DCP mutation message have extra information to indicate it was triggered by eventing function ?

The mutation will be present in DCP. But the Function which generated it(because of the update from within the Function) will ignore it - so that recursive mutations do not create a domino and bring down the cluster.

(the above is being considered as we speak for implementation to manage recursive behaviour. stay tuned!)

1 Like

This is coded and ready to go in the upcoming release. It will be safe to modify documents from the same bucket that is source of the event handler.

Thanks,
Siri