ECELLORS CRM Blog

IExecutionContext.Depth Property:

Today would like to share with all of Dynamics CRM folks about the important Depth property used to prevent plugins going into infinite loop.

This is property name which tracks the Depth property of plugins in ms crm.

Gets the current depth of execution in the call stack and available in the context which is being passed to plugin.

Syntax:

int Depth { get; }

Notes:
This property is basically used by the platform for infinite loop prevention. very time a running plug-in 
or when workflow issues a message request to the web services that triggers 
another plugin or workflow to execute, the Depth property of the execution 
context is increased. If the depth property increments to its maximum value
within the configured time limit, the platform considers this behavior an 
infinite loop and further plug-in or Workflow execution is aborted.The max-
imum depth (8) and permissible time limit (one hour) are configurable by the Microsoft 
Dynamics CRM administrator by default.

If required, this setting can be changed by a powershell command
PowerShell command -- Set-CrmSetting. 

Depth is the number of times a plugin/custom workflow has been called in 
one transaction. Depth is often used to stop infinite loops where a plugin 
updates a value which triggers the plugin to run again. When a plugin/custom 
workflow triggers another plugin/trigger then the depth property is increm-
ented by one.The depth value has a maximum value called 
WorkflowSettings.MaxDepth. 
The CRM SDK (Depth)states this is set to maximum depth of 8 within one hour
and common method to avoid a recurring plugin is to check if  a plugins 
depth > 1.
This would stop the plugins from being run if was triggered from any other
plugin. The plugin would only run if triggered from the CRM form only.


Alternate solution is to use shared variables which can pass data between plugins
registered in different stages in a transaction. Eg.You can use ShareVariables 
to pass information between plugins registered on different stages but in the 
same transaction e.g a pre plugin can pass information to a post plugin.


Details can be observed better @ use shared variables in plugins

Update: 11/26/2018

Scenario:

Think of situation where the Plugin is registered on Update of an Entity with filtering attributes set to a field in the Entity.

Due to some bad coding logic, the Plugin registered is also updating the same field.

This would call the same plugin once more causing infinite loop.

This is where using Depth becomes significant.

Thank you.

Cheers,

PMDY