search

mitchspano / apex-trigger-actions-framework

A framework for partitioning, ordering, and bypassing trigger logic for applications built on Salesforce.
Apache License 2.0
510 stars 158 forks source link

Multiple calls to MetadataTriggerHandler().run() #142

Closed pasres closed 6 months ago

pasres commented 7 months ago

Disclaimer: I know the framework works as intended, so this is more of an open question. I'll still put it in the form of an issue. Please feel free to just dismiss and close it if you feel this is beyond the scope of the framework. Thanks in advance!

Expected Behavior

Actual Behavior

Steps to Reproduce the Problem

  1. Add 2 triggers on Account, both calling MetadataTriggerHandler().run()
  2. Add SObject_Trigger_Setting__mdt for Account
  3. Add one Trigger_Action__mdt calling some code
  4. Execute UI or other change to run trigger

Specifications

Background: We are developing 2GP managed packages. We would like to package the framework (think of it as a commons/utilities package) and have other packages depend on it. This could lead to multiple triggers on the same object calling the framework entry point (MetadataTriggerHandler) thus running triggers multiple times. We are now wondering how to best prevent this (besides manual code review) - if that's even possible. I understand the framework was probably not created with this kind of use case in mind, but maybe it is something worth considering.

mitchspano commented 7 months ago

You should not have two triggers on the same SObject calling MetadataTriggerHandler().run(). The framework is specifically built to handle the orchestration of all trigger logic from one injection point. In the case of a package trigger, there should only ever be one trigger on the SObject which would be included int he package itself. Clients can then implement the trigger action interfaces and add new logic via custom metadata and retain the single injection point.

pasres commented 6 months ago

Thanks for getting back with the info. We also came to the conclusion that it would be best to package the triggers toghether with the framework. Additionally we implemented it so that the framework entrypoint is not "Namespaceaccessible", so any potential second trigger from another package can't actually call it.