Ability to specify custom readPreference for beforeSave's internal validation

[refre5h]

New Feature / Enhancement Checklist

• Report security issues confidentially.
• Any contribution is under this license.
• Before posting search existing issues.

Current Limitation

We have a multi-region deployment of parse-server with mongodb. The main region is where the primary db node resides (responsible for writes). The rest are secondary regions with read-only db nodes. The secondary regions read from their nearest read-only db node for speed (readPreference=nearest).

We have logic where a new object is created, then immediately followed by some updates of that new object, like this:

const newObject = await new Parse.Object('ThisClass').save()
... // some other necessary logic
await newObject.set({'key': 'val'}).save()

ThisClass has a beforeSave trigger implemented.

This works most of the time until parse-server throw an "Object not found" error in a secondary region where there's only a read-only db node.

Upon digging the source, we believe this is where the error occurs: https://github.com/parse-community/parse-server/blob/alpha/src/RestWrite.js#L249-L275

It appears that parse-server does some internal validation of the object in beforeSave triggers. But the newly created object has not been propagated to the secondary db node where this validation occurs, causing the "Object not found" error.

Feature / Enhancement Description

Parse Query has a method query.readPreference('PRIMARY') for situation like this. However, that doesn't work in beforeSave because the fetch is done internally.

We tried a few workarounds (see below), but none of them can guarantee data consistancy while keeping the fast read speed at the same time.

Being able to specify the read preference for this internal validation in beforeSave triggers seems necessary for multi-region setups to achieve both data consistancy and optimized read performance.

Example Use Case

Explained above.

Alternatives / Workarounds

1. Set a delay before updating the newly created object. This reduces the changes of the error, but it's slow and still can't guarantee 100% success.
2. w=majority improves the situation, but can't guarantee the data is there when the beforeSave occurs.
3. Set readPreference=primary globally. This fixes the error, but it completely defeats the purpose of having a multi-region setup for enhanced read.

[parse-github-assistant]

🚀 Thanks for opening this issue! We are excited about your ideas for improvement!

[mtrezza]

Interesting find. So the read pref should be specifiable per trigger invocation? A obj save can be triggered from a client or the server via Cloud Code. For the client, we probably don't want to expose this API, but when calling it from within Cloud Code it could be an additional option for triggers.

await obj.save(null, { triggerReadPreference: 'PRIMARY' });

We could also set this as part of the server config, so that it applies to all triggers by default and specifying it as a save option is just for override.

[refre5h]

In our use case, a global setting (like parse config) that forces all trigger to read from PRIMARY would be enough. However, I do see that having it specifiable per trigger invocation is more flexible.

Only allowing in within Cloud Code makes perfect sense!

[mtrezza]

Maybe reducing to a global setting for now would be sufficient. Do you want to open a PR?