Dynamics 365 Business Central: breaking change when adding a return value to a procedure

I’ve received a request from a partner asking why adding a return value to a procedure in a Dynamics 365 Business Central extension that previously had no return value is considered a breaking change during AppSource validation.

The explicit question was: “if previously I had a dependent extension that uses the first version of this procedure (the version without return value) and now I add a return value to the procedure, the dependent extension should not be broken because it simply ignores the return value. I know that you cannot change the type of the return value or remove it, but why adding a return value is a breaking change?“.

To better explain the scenario, imagine to have published a version 1.0.0.0 of an app with a procedure like the following:

In a new 2.0.0.0 version of our app, we add a new return value to the procedure, like in the following example:

If you validate the new version and you check breaking change from the first version, you will have the following result:

error AS0102: It is not allowed to add a return value to procedure 'DemoProcedure' on object 'SD Demo Codeunit', because it might break dependent extensions at runtime.

What does that means?

Breaking changes on extensions can be summarize as per the following types:

  • Breaking changes on database schema: these happens when you remove objects like table or fields and the app cannot be synced anymore (only possible by using ForceSync or SyncClean)
  • Breaking changes on compilation: these are changes that can cause error on compiling dependent extensions (for example like changing parameters on a procedure)
  • Breaking changes on runtime: these are breaking changes that cause runtime issues when using the app.

In this case, we have a runtime breaking change. Adding a return type to a procedure that previously had no return type changes the internal method ID used by the server runtime to call the function. If the dependent extensions referencing the procedure are not recompiled, they will use the old method ID and this will cause runtime issues due to the ID mismatch (you can have errors like “function ID in object XX cannot be found“).

Please remember this and also remember to always validate your apps before submitting. You will catch lots of these errors.

3 Comments

  1. Thanks for writing this blog post to warn us all for this kind of breaking change.

    There is however the question whether a procedure should get a new internal id assigned, as this is not something that we can determine or assign in code (as we could back in the days in C/AL). It’s a choice that is made in the platform by Microsoft, which leads to this breaking change based on runtime errors. What is the reason for assigning a new internal id? What’s the reason the already existing id cannot be used by the system? Should that not be changed/corrected/further developed?

    In the meantime, as mentioned, it’s good to know that this kind of breaking change exists.

    Like

    1. This is how actually the AL compiler works internally. When you create a procedure, it assigns an internal ID. This ID is never changed unless you modify the procedure signature (and this is a breaking change for the platform).

      Like

      1. That is currently how the AL compiler works indeed. This does however, in my opinion, not mean that some behavior shouldn’t be considered to be optimized by Microsoft.

        Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.