Bypass Infinity loop in Hooks

[wikoci]

Do you have any options to bypass all hooks when using the local API.
In order to avoid loop in hooks between two collections or fields.

Example :

A-Collection
-Hook afterChange update something in CB

B-Collection

• Hook afterChange
  update something in CA.

[jmikrut]

Hey @wikoci — this is a pretty common problem with many dev tasks. Generally we'd say the right way to do this would be to store some type of flag that lets you know that whatever the hook was needed for has been done, so you can not update the document again. But, if you wanted to avoid triggering hooks, you could access the Mongoose model directly, and update whatever you need directly with the Mongoose model.

You can access Mongoose models by payload.collections[collectionSlug].Model.

Another way would be to bind something to the req like .... payloadHooksHaveRun: true or similar? And then in your hooks, check for that flag?

One of the options above should work for you. I'm going to convert this to a discussion because it's not necessarily something that Payload should tackle, moreso just a good discussion about how to avoid infinite loops with hooks.

Very good question! 👍

[ssyberg]

Can you give a simple example of binding a flag to req in this scenario? I've tried simply setting this on req within the hook but that does not appear to persist.

[ssyberg]

For anyone who ends up here, I was able to accomplish this with a dirty bit, though would definitely prefer binding to req or leveraging something in core, this feels messy/brittle and very not DRY if it's common in your app.

import { CollectionConfig } from 'payload/types';

// Example Collection - For reference only, this must be added to payload.config.ts to be used.
const Examples: CollectionConfig = {
    slug: 'examples',
    versions: {
        drafts: true,
    },
    fields: [
        {
            name: 'fieldNotRequired',
            type: 'text',
        },
        {
            name: 'fieldRequired',
            type: 'text',
            required: true,
        },
        {
            name: 'dirty',
            type: 'checkbox',
            defaultValue: true,
            admin: {
                hidden: true,
            },
        },
    ],
    hooks: {
        afterChange: [
            async ({ doc, operation, req }) => {
                if (doc.dirty) {
                    await req.payload.update({
                        collection: 'examples',
                        id: doc.id,
                        data: {
                            fieldNotRequired: 'foo',
                            dirty: false,
                            _status: doc._status,
                        },
                    });
                }
            },
        ],
    },
};

export default Examples;

[miguelvictor]

Not sure if this is a bug or not but you can tell that the hook has started to be in the loop if 'req.user' is already falsy.

[ssyberg]

Yea I think there are a bunch of indicators like that and I use some of them but it makes me a bit nervous. Since it's not documented behavior none of them are really guaranteed and as such might not be highlighted in release notes as breaking changes...

[JoschuaSchneider]

We experienced a similar Problem with afterRead hooks on fields.

We have a collection of articles and want to add a previousArticleSlug and nextArticleSlug based on the dates of articles.

When we use payload.find() inside the hook, we run into an infinite loop because each find triggers hooks on the target article and so on.

We worked around this using a flag outside of the hook, that is set in the initial hook call, and cleaned up after the first find (every subsequent find is therefore skipped).

The direct access of the mongoose model would also be a workaround for this, but the find/update abstractions from payload feel a bit nicer to use.

I would've proposed adding an option like skipHooks: HookType[] before finding this discussion. So that you can fire off queries and mutations inside hooks, knowing that they wont trigger subsequent hook calls.

I'm open to contribute on a PR for a feature like that if that is something you are interested in.

[chladog]

I'm encoutering this problem quite often. And the proposed solutions work, unfortunatelly none of them is clean (e.g. flag on req throws typing err and it force you to actually pass req object to all subsequent Local API calls which can alter something you do not wish (user object, access, locale) and also is not possible to pass to some Local API calls like typed payload.update; and mongoose way doesn't trigger any hook at all which is not good if you need to skip or alter only one hook). This gets painful as you get more complex hooks flow.

I propose following solution:

adding a new property to Local API actions context or ctx with type {[key: string]: any}. By default ctx would be {} or undefined and would be passed as an arg to all subsequent hooks triggered from the action that declared it.
Any hook would be able to read it and modify it on the way to the next hook (and you could optionally pass it to new LocalAPI call). After the last action there would be no reference and JS would GCed it automatically.

[ssyberg]

This is in the works for the request object context, I completely agree this should also exist on all API actions