Why an async plug-in that raises InvalidPluginExecutionException does not retry
Short answer
B Dataverse async plug-ins do not automatically retry, so raising an InvalidPluginExecutionException cannot satisfy the retry-on-500 requirement.
Question
Key Takeaways
InvalidPluginExecutionException cancels/rolls back the operation; it does not configure retries. Dataverse does not automatically retry asynchronous plug-in executions, so a transient 500 from the REST API will simply fail rather than be retried.
An integration sends created Dataverse records to a REST API and must retry when the API returns 500. The proposed solution registers an async plug-in and raises InvalidPluginExecutionException to trigger retry. Dataverse asynchronous plug-ins do not auto-retry on failure, so the requirement is not met.
Common mistake: Assuming raising an exception 'configures a retry.' Exceptions signal failure, they do not schedule retries. The correct retry pattern uses a durable queue (Azure Service Bus) with a dead-letter queue, not a plug-in exception.
Expert Analysis
Why the Answer Is Correct
Dataverse asynchronous plug-ins are not automatically retried when they fail. Raising an InvalidPluginExecutionException merely aborts the operation and records the error; it does not instruct the platform to re-execute the step. Therefore the solution cannot guarantee a retry when the REST API returns 500.
Why the Other Options Are Wrong
There is no 'A. Yes' path that is correct here. The false assumption is that an exception triggers retry; in Dataverse it does not. A durable messaging pattern (Service Bus queue plus dead-letter queue) is the supported way to achieve retry semantics.
Community Comment Notes
busitecgmbh (likes=3) states that raising InvalidPluginExecutionException cancels the process and cannot be configured to retry. loftuscheek (likes=1) and KucaStonojka (likes=2) both confirm async plug-ins do not auto-retry by default.
Official Reference
https://learn.microsoft.com/en-us/power-apps/developer/data-platform/plug-ins
This link opens the official vendor documentation in a new tab.
Community Votes
78% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 6 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 6
-
busitecgmbh 👍 3 Answered BNo, if a InvalidPluginExecutionException is raised the process is cancelled and can't be configured to retry.
-
KucaStonojka 👍 2 Answered BRaising an InvalidPluginExecutionException does not fulfill the retry requirement.
-
Juan0414 👍 1 Answered AYes for me. Documentation states this: Retry an asynchronous plug-in With an asynchronous plug-in step, you can retry when a plug-in fails. The cause of the failure may be due to a network error or some other retriable error calling an external resource. To retry your plug-in, use the InvalidPluginExecutionException(OperationStatus, Int32, String) constructor using the OperationStatus Enum Retry member value. When your plug-in throws this type of exception, the asynchronous service attempts to execute your plug-in four times. If the plug-in execution doesn't succeed within four attempts, the call fails. https://learn.microsoft.com/en-us/power-apps/developer/data-platform/handle-exceptions#retry-an-asynchronous-plug-in
-
loftuscheek 👍 1 Answered BExplanation: Asynchronous plug-ins in Dataverse do not automatically retry upon failure. Even if an InvalidPluginExecutionException is raised, Dataverse does not retry asynchronous plug-ins by default. Retries in plug-ins are only applicable to synchronous transactions within the same execution pipeline. However, the requirement here is to retry when an external REST API returns a 500 status code, which is an external system failure, not an internal Dataverse transaction failure.
-
OlenaChep 👍 1 Answered BIn task we have: when the Rest API is unavailable. According to documentation: The purpose of the dead-letter queue is to hold messages that can't be delivered to any receiver, or messages that couldn't be processed. Messages can then be removed from the DLQ and inspected. An application might let a user correct issues and resubmit the message. In our situation we have nothing to fix. I think it is conceptually wrong to use a dead letter queue in this case.
Show 1 more comment
-
sudoaptupgrade 👍 1 Answered AYes, because this time it is configured to retry after raising the exception
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All PL-400 Questions
Access 85 questions with complete answers and detailed explanations.
View Full PL-400 Practice Test →