Value provided is invalid for action parameter [VAR] of type 'String'" instead












12















Seems like upcoming changes in Spring 19 are causing us issues with "AuraEnabled" methods. Since forever now, primitive types were sent from Aura to APEX as String only as explained here: https://salesforce.stackexchange.com/a/245733/42188.



While the change explained in the previous post is beneficial (parsing primitives), it breaks older setups (or older manage packages).



Let's assume you had a Lightning component sending a boolean value to an APEX method. The APEX signature would've look like



@AuraEnabled
public static string myMethod(String myBoolValue)


with the Aura call



var action= component.get("c.myMethod");
removeAction.setParams({
"myBoolValue": true
});


Since the boolean value sent by Aura is now correctly parsed as a bool (previously, it was sent as a string), APEX now returns a "Value provided is invalid for action parameter myBoolValue of type 'String'" instead" error for the same code.



From what we can see, that change isn't tied to a Critical Update.



While the "fix" is pretty simple (just change the apex signature to accept a bool instead), this isn't really an option for ISVs with multiple managed packages installed everywhere that will just "stop working" when the Spring 19 rollout will be completed.



Would it be possible for Salesforce to be backwards compatible ?
Seems like we won't be the only ones to have that issue and Salesforce isn't really known to introduce breaking changes (or at least, not force a breaking change).










share|improve this question





























    12















    Seems like upcoming changes in Spring 19 are causing us issues with "AuraEnabled" methods. Since forever now, primitive types were sent from Aura to APEX as String only as explained here: https://salesforce.stackexchange.com/a/245733/42188.



    While the change explained in the previous post is beneficial (parsing primitives), it breaks older setups (or older manage packages).



    Let's assume you had a Lightning component sending a boolean value to an APEX method. The APEX signature would've look like



    @AuraEnabled
    public static string myMethod(String myBoolValue)


    with the Aura call



    var action= component.get("c.myMethod");
    removeAction.setParams({
    "myBoolValue": true
    });


    Since the boolean value sent by Aura is now correctly parsed as a bool (previously, it was sent as a string), APEX now returns a "Value provided is invalid for action parameter myBoolValue of type 'String'" instead" error for the same code.



    From what we can see, that change isn't tied to a Critical Update.



    While the "fix" is pretty simple (just change the apex signature to accept a bool instead), this isn't really an option for ISVs with multiple managed packages installed everywhere that will just "stop working" when the Spring 19 rollout will be completed.



    Would it be possible for Salesforce to be backwards compatible ?
    Seems like we won't be the only ones to have that issue and Salesforce isn't really known to introduce breaking changes (or at least, not force a breaking change).










    share|improve this question



























      12












      12








      12


      4






      Seems like upcoming changes in Spring 19 are causing us issues with "AuraEnabled" methods. Since forever now, primitive types were sent from Aura to APEX as String only as explained here: https://salesforce.stackexchange.com/a/245733/42188.



      While the change explained in the previous post is beneficial (parsing primitives), it breaks older setups (or older manage packages).



      Let's assume you had a Lightning component sending a boolean value to an APEX method. The APEX signature would've look like



      @AuraEnabled
      public static string myMethod(String myBoolValue)


      with the Aura call



      var action= component.get("c.myMethod");
      removeAction.setParams({
      "myBoolValue": true
      });


      Since the boolean value sent by Aura is now correctly parsed as a bool (previously, it was sent as a string), APEX now returns a "Value provided is invalid for action parameter myBoolValue of type 'String'" instead" error for the same code.



      From what we can see, that change isn't tied to a Critical Update.



      While the "fix" is pretty simple (just change the apex signature to accept a bool instead), this isn't really an option for ISVs with multiple managed packages installed everywhere that will just "stop working" when the Spring 19 rollout will be completed.



      Would it be possible for Salesforce to be backwards compatible ?
      Seems like we won't be the only ones to have that issue and Salesforce isn't really known to introduce breaking changes (or at least, not force a breaking change).










      share|improve this question
















      Seems like upcoming changes in Spring 19 are causing us issues with "AuraEnabled" methods. Since forever now, primitive types were sent from Aura to APEX as String only as explained here: https://salesforce.stackexchange.com/a/245733/42188.



      While the change explained in the previous post is beneficial (parsing primitives), it breaks older setups (or older manage packages).



      Let's assume you had a Lightning component sending a boolean value to an APEX method. The APEX signature would've look like



      @AuraEnabled
      public static string myMethod(String myBoolValue)


      with the Aura call



      var action= component.get("c.myMethod");
      removeAction.setParams({
      "myBoolValue": true
      });


      Since the boolean value sent by Aura is now correctly parsed as a bool (previously, it was sent as a string), APEX now returns a "Value provided is invalid for action parameter myBoolValue of type 'String'" instead" error for the same code.



      From what we can see, that change isn't tied to a Critical Update.



      While the "fix" is pretty simple (just change the apex signature to accept a bool instead), this isn't really an option for ISVs with multiple managed packages installed everywhere that will just "stop working" when the Spring 19 rollout will be completed.



      Would it be possible for Salesforce to be backwards compatible ?
      Seems like we won't be the only ones to have that issue and Salesforce isn't really known to introduce breaking changes (or at least, not force a breaking change).







      apex lightning aura spring19






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 21 at 20:12







      Andre Theriault

















      asked Jan 21 at 19:59









      Andre TheriaultAndre Theriault

      635




      635






















          1 Answer
          1






          active

          oldest

          votes


















          5














          Probably not, as there's no mention of this fix being "versioned" (meaning, dependent on the API version). Unfortunately, this is a case of using the wrong workaround for a Salesforce bug. The value should have been converted to a String in the JS code by the developer, or used JSON encoding, etc.



          Note that this bug is already being deployed, so it's too late to do anything about it from the Salesforce side. If you're an ISV, and in this position, you should be preparing a patch for your customers right now. This is one of the benefits of having an ISV status, is that you can patch the code without forcing your clients to individually upgrade.



          This is known as a Push Upgrade. You can conveniently and automatically push this update to your subscribers for a seamless experience. In the future, please consider the possible impacts of what happens if you're using a bug and what would happen if that bug was mysteriously fixed when you woke up one day.



          Ultimately, I suspect that this was not versioned so that ISVs wouldn't be put in a situation where they allowed the bug to persist and cause future headaches (imagine, you develop a new feature, update the API version, only to have this bug mysteriously appear). Forcing the fix now is designed to prevent future problems, so it's probably for the best.






          share|improve this answer
























          • I agree with you that the change is beneficial for the long run. Calling it "using a bug" is a bit far fetched since the auto-convert to string was well documented and well known for years now. It was a way to bypass a known limitation. Doesn't change the fact that we need to change it though. But we are in the process of deploying a patch. We hope to raise awareness with that post more than anything for others in the same situation.

            – Andre Theriault
            Jan 21 at 20:35













          • @AndreTheriault I don't mean anything malicious by it, to be sure. I'm just saying that, as developers, we should be make sure our solutions won't readily break if the bug were fixed, rather than using the bug as a feature (in this case, automatic type coercion). On the other hand, I'm pretty sure the reason why I'm always so paranoid about that is I've made similar mistakes while working around bugs as an ISV in the past--I've learned my lesson.

            – sfdcfox
            Jan 21 at 20:59











          • Totally agree, like you said, unfortunately, this is a case of using the wrong workaround for a Salesforce bug. Thanks for you input on this, much appreciated.

            – Andre Theriault
            Jan 21 at 21:01













          • older implementation actually didn't do what you may have thought. There was no auto conversion being done and Apex used to get invoked with incorrect dataType (passing in a json boolean/number for a parameter when Apex method signature said that its a String). That could have resulted incorrect control flow (conditional code not doing what the dev intended) or internal server error (apex runtime flagging incompatibility). Updated logic, strives to make things upfront and predictable.

            – Emad Salman
            Jan 22 at 5:29











          • For example, Try calling myBoolValue.capitalize() from the example above on a server that hasn't been updated yet and you'll see 'System.UnexpectedException: Illegal arguments' in apex logs and internal server error on client. In any case, for 'String' arguments in particular, we have decided (in one of the upcoming patch releases) to update the new logic to accept number/boolean values and stringify them to mimic what users may have thought was happening originally :)

            – Emad Salman
            Jan 22 at 5:41













          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "459"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f247438%2fvalue-provided-is-invalid-for-action-parameter-var-of-type-string-instead%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          5














          Probably not, as there's no mention of this fix being "versioned" (meaning, dependent on the API version). Unfortunately, this is a case of using the wrong workaround for a Salesforce bug. The value should have been converted to a String in the JS code by the developer, or used JSON encoding, etc.



          Note that this bug is already being deployed, so it's too late to do anything about it from the Salesforce side. If you're an ISV, and in this position, you should be preparing a patch for your customers right now. This is one of the benefits of having an ISV status, is that you can patch the code without forcing your clients to individually upgrade.



          This is known as a Push Upgrade. You can conveniently and automatically push this update to your subscribers for a seamless experience. In the future, please consider the possible impacts of what happens if you're using a bug and what would happen if that bug was mysteriously fixed when you woke up one day.



          Ultimately, I suspect that this was not versioned so that ISVs wouldn't be put in a situation where they allowed the bug to persist and cause future headaches (imagine, you develop a new feature, update the API version, only to have this bug mysteriously appear). Forcing the fix now is designed to prevent future problems, so it's probably for the best.






          share|improve this answer
























          • I agree with you that the change is beneficial for the long run. Calling it "using a bug" is a bit far fetched since the auto-convert to string was well documented and well known for years now. It was a way to bypass a known limitation. Doesn't change the fact that we need to change it though. But we are in the process of deploying a patch. We hope to raise awareness with that post more than anything for others in the same situation.

            – Andre Theriault
            Jan 21 at 20:35













          • @AndreTheriault I don't mean anything malicious by it, to be sure. I'm just saying that, as developers, we should be make sure our solutions won't readily break if the bug were fixed, rather than using the bug as a feature (in this case, automatic type coercion). On the other hand, I'm pretty sure the reason why I'm always so paranoid about that is I've made similar mistakes while working around bugs as an ISV in the past--I've learned my lesson.

            – sfdcfox
            Jan 21 at 20:59











          • Totally agree, like you said, unfortunately, this is a case of using the wrong workaround for a Salesforce bug. Thanks for you input on this, much appreciated.

            – Andre Theriault
            Jan 21 at 21:01













          • older implementation actually didn't do what you may have thought. There was no auto conversion being done and Apex used to get invoked with incorrect dataType (passing in a json boolean/number for a parameter when Apex method signature said that its a String). That could have resulted incorrect control flow (conditional code not doing what the dev intended) or internal server error (apex runtime flagging incompatibility). Updated logic, strives to make things upfront and predictable.

            – Emad Salman
            Jan 22 at 5:29











          • For example, Try calling myBoolValue.capitalize() from the example above on a server that hasn't been updated yet and you'll see 'System.UnexpectedException: Illegal arguments' in apex logs and internal server error on client. In any case, for 'String' arguments in particular, we have decided (in one of the upcoming patch releases) to update the new logic to accept number/boolean values and stringify them to mimic what users may have thought was happening originally :)

            – Emad Salman
            Jan 22 at 5:41


















          5














          Probably not, as there's no mention of this fix being "versioned" (meaning, dependent on the API version). Unfortunately, this is a case of using the wrong workaround for a Salesforce bug. The value should have been converted to a String in the JS code by the developer, or used JSON encoding, etc.



          Note that this bug is already being deployed, so it's too late to do anything about it from the Salesforce side. If you're an ISV, and in this position, you should be preparing a patch for your customers right now. This is one of the benefits of having an ISV status, is that you can patch the code without forcing your clients to individually upgrade.



          This is known as a Push Upgrade. You can conveniently and automatically push this update to your subscribers for a seamless experience. In the future, please consider the possible impacts of what happens if you're using a bug and what would happen if that bug was mysteriously fixed when you woke up one day.



          Ultimately, I suspect that this was not versioned so that ISVs wouldn't be put in a situation where they allowed the bug to persist and cause future headaches (imagine, you develop a new feature, update the API version, only to have this bug mysteriously appear). Forcing the fix now is designed to prevent future problems, so it's probably for the best.






          share|improve this answer
























          • I agree with you that the change is beneficial for the long run. Calling it "using a bug" is a bit far fetched since the auto-convert to string was well documented and well known for years now. It was a way to bypass a known limitation. Doesn't change the fact that we need to change it though. But we are in the process of deploying a patch. We hope to raise awareness with that post more than anything for others in the same situation.

            – Andre Theriault
            Jan 21 at 20:35













          • @AndreTheriault I don't mean anything malicious by it, to be sure. I'm just saying that, as developers, we should be make sure our solutions won't readily break if the bug were fixed, rather than using the bug as a feature (in this case, automatic type coercion). On the other hand, I'm pretty sure the reason why I'm always so paranoid about that is I've made similar mistakes while working around bugs as an ISV in the past--I've learned my lesson.

            – sfdcfox
            Jan 21 at 20:59











          • Totally agree, like you said, unfortunately, this is a case of using the wrong workaround for a Salesforce bug. Thanks for you input on this, much appreciated.

            – Andre Theriault
            Jan 21 at 21:01













          • older implementation actually didn't do what you may have thought. There was no auto conversion being done and Apex used to get invoked with incorrect dataType (passing in a json boolean/number for a parameter when Apex method signature said that its a String). That could have resulted incorrect control flow (conditional code not doing what the dev intended) or internal server error (apex runtime flagging incompatibility). Updated logic, strives to make things upfront and predictable.

            – Emad Salman
            Jan 22 at 5:29











          • For example, Try calling myBoolValue.capitalize() from the example above on a server that hasn't been updated yet and you'll see 'System.UnexpectedException: Illegal arguments' in apex logs and internal server error on client. In any case, for 'String' arguments in particular, we have decided (in one of the upcoming patch releases) to update the new logic to accept number/boolean values and stringify them to mimic what users may have thought was happening originally :)

            – Emad Salman
            Jan 22 at 5:41
















          5












          5








          5







          Probably not, as there's no mention of this fix being "versioned" (meaning, dependent on the API version). Unfortunately, this is a case of using the wrong workaround for a Salesforce bug. The value should have been converted to a String in the JS code by the developer, or used JSON encoding, etc.



          Note that this bug is already being deployed, so it's too late to do anything about it from the Salesforce side. If you're an ISV, and in this position, you should be preparing a patch for your customers right now. This is one of the benefits of having an ISV status, is that you can patch the code without forcing your clients to individually upgrade.



          This is known as a Push Upgrade. You can conveniently and automatically push this update to your subscribers for a seamless experience. In the future, please consider the possible impacts of what happens if you're using a bug and what would happen if that bug was mysteriously fixed when you woke up one day.



          Ultimately, I suspect that this was not versioned so that ISVs wouldn't be put in a situation where they allowed the bug to persist and cause future headaches (imagine, you develop a new feature, update the API version, only to have this bug mysteriously appear). Forcing the fix now is designed to prevent future problems, so it's probably for the best.






          share|improve this answer













          Probably not, as there's no mention of this fix being "versioned" (meaning, dependent on the API version). Unfortunately, this is a case of using the wrong workaround for a Salesforce bug. The value should have been converted to a String in the JS code by the developer, or used JSON encoding, etc.



          Note that this bug is already being deployed, so it's too late to do anything about it from the Salesforce side. If you're an ISV, and in this position, you should be preparing a patch for your customers right now. This is one of the benefits of having an ISV status, is that you can patch the code without forcing your clients to individually upgrade.



          This is known as a Push Upgrade. You can conveniently and automatically push this update to your subscribers for a seamless experience. In the future, please consider the possible impacts of what happens if you're using a bug and what would happen if that bug was mysteriously fixed when you woke up one day.



          Ultimately, I suspect that this was not versioned so that ISVs wouldn't be put in a situation where they allowed the bug to persist and cause future headaches (imagine, you develop a new feature, update the API version, only to have this bug mysteriously appear). Forcing the fix now is designed to prevent future problems, so it's probably for the best.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 21 at 20:25









          sfdcfoxsfdcfox

          254k11198438




          254k11198438













          • I agree with you that the change is beneficial for the long run. Calling it "using a bug" is a bit far fetched since the auto-convert to string was well documented and well known for years now. It was a way to bypass a known limitation. Doesn't change the fact that we need to change it though. But we are in the process of deploying a patch. We hope to raise awareness with that post more than anything for others in the same situation.

            – Andre Theriault
            Jan 21 at 20:35













          • @AndreTheriault I don't mean anything malicious by it, to be sure. I'm just saying that, as developers, we should be make sure our solutions won't readily break if the bug were fixed, rather than using the bug as a feature (in this case, automatic type coercion). On the other hand, I'm pretty sure the reason why I'm always so paranoid about that is I've made similar mistakes while working around bugs as an ISV in the past--I've learned my lesson.

            – sfdcfox
            Jan 21 at 20:59











          • Totally agree, like you said, unfortunately, this is a case of using the wrong workaround for a Salesforce bug. Thanks for you input on this, much appreciated.

            – Andre Theriault
            Jan 21 at 21:01













          • older implementation actually didn't do what you may have thought. There was no auto conversion being done and Apex used to get invoked with incorrect dataType (passing in a json boolean/number for a parameter when Apex method signature said that its a String). That could have resulted incorrect control flow (conditional code not doing what the dev intended) or internal server error (apex runtime flagging incompatibility). Updated logic, strives to make things upfront and predictable.

            – Emad Salman
            Jan 22 at 5:29











          • For example, Try calling myBoolValue.capitalize() from the example above on a server that hasn't been updated yet and you'll see 'System.UnexpectedException: Illegal arguments' in apex logs and internal server error on client. In any case, for 'String' arguments in particular, we have decided (in one of the upcoming patch releases) to update the new logic to accept number/boolean values and stringify them to mimic what users may have thought was happening originally :)

            – Emad Salman
            Jan 22 at 5:41





















          • I agree with you that the change is beneficial for the long run. Calling it "using a bug" is a bit far fetched since the auto-convert to string was well documented and well known for years now. It was a way to bypass a known limitation. Doesn't change the fact that we need to change it though. But we are in the process of deploying a patch. We hope to raise awareness with that post more than anything for others in the same situation.

            – Andre Theriault
            Jan 21 at 20:35













          • @AndreTheriault I don't mean anything malicious by it, to be sure. I'm just saying that, as developers, we should be make sure our solutions won't readily break if the bug were fixed, rather than using the bug as a feature (in this case, automatic type coercion). On the other hand, I'm pretty sure the reason why I'm always so paranoid about that is I've made similar mistakes while working around bugs as an ISV in the past--I've learned my lesson.

            – sfdcfox
            Jan 21 at 20:59











          • Totally agree, like you said, unfortunately, this is a case of using the wrong workaround for a Salesforce bug. Thanks for you input on this, much appreciated.

            – Andre Theriault
            Jan 21 at 21:01













          • older implementation actually didn't do what you may have thought. There was no auto conversion being done and Apex used to get invoked with incorrect dataType (passing in a json boolean/number for a parameter when Apex method signature said that its a String). That could have resulted incorrect control flow (conditional code not doing what the dev intended) or internal server error (apex runtime flagging incompatibility). Updated logic, strives to make things upfront and predictable.

            – Emad Salman
            Jan 22 at 5:29











          • For example, Try calling myBoolValue.capitalize() from the example above on a server that hasn't been updated yet and you'll see 'System.UnexpectedException: Illegal arguments' in apex logs and internal server error on client. In any case, for 'String' arguments in particular, we have decided (in one of the upcoming patch releases) to update the new logic to accept number/boolean values and stringify them to mimic what users may have thought was happening originally :)

            – Emad Salman
            Jan 22 at 5:41



















          I agree with you that the change is beneficial for the long run. Calling it "using a bug" is a bit far fetched since the auto-convert to string was well documented and well known for years now. It was a way to bypass a known limitation. Doesn't change the fact that we need to change it though. But we are in the process of deploying a patch. We hope to raise awareness with that post more than anything for others in the same situation.

          – Andre Theriault
          Jan 21 at 20:35







          I agree with you that the change is beneficial for the long run. Calling it "using a bug" is a bit far fetched since the auto-convert to string was well documented and well known for years now. It was a way to bypass a known limitation. Doesn't change the fact that we need to change it though. But we are in the process of deploying a patch. We hope to raise awareness with that post more than anything for others in the same situation.

          – Andre Theriault
          Jan 21 at 20:35















          @AndreTheriault I don't mean anything malicious by it, to be sure. I'm just saying that, as developers, we should be make sure our solutions won't readily break if the bug were fixed, rather than using the bug as a feature (in this case, automatic type coercion). On the other hand, I'm pretty sure the reason why I'm always so paranoid about that is I've made similar mistakes while working around bugs as an ISV in the past--I've learned my lesson.

          – sfdcfox
          Jan 21 at 20:59





          @AndreTheriault I don't mean anything malicious by it, to be sure. I'm just saying that, as developers, we should be make sure our solutions won't readily break if the bug were fixed, rather than using the bug as a feature (in this case, automatic type coercion). On the other hand, I'm pretty sure the reason why I'm always so paranoid about that is I've made similar mistakes while working around bugs as an ISV in the past--I've learned my lesson.

          – sfdcfox
          Jan 21 at 20:59













          Totally agree, like you said, unfortunately, this is a case of using the wrong workaround for a Salesforce bug. Thanks for you input on this, much appreciated.

          – Andre Theriault
          Jan 21 at 21:01







          Totally agree, like you said, unfortunately, this is a case of using the wrong workaround for a Salesforce bug. Thanks for you input on this, much appreciated.

          – Andre Theriault
          Jan 21 at 21:01















          older implementation actually didn't do what you may have thought. There was no auto conversion being done and Apex used to get invoked with incorrect dataType (passing in a json boolean/number for a parameter when Apex method signature said that its a String). That could have resulted incorrect control flow (conditional code not doing what the dev intended) or internal server error (apex runtime flagging incompatibility). Updated logic, strives to make things upfront and predictable.

          – Emad Salman
          Jan 22 at 5:29





          older implementation actually didn't do what you may have thought. There was no auto conversion being done and Apex used to get invoked with incorrect dataType (passing in a json boolean/number for a parameter when Apex method signature said that its a String). That could have resulted incorrect control flow (conditional code not doing what the dev intended) or internal server error (apex runtime flagging incompatibility). Updated logic, strives to make things upfront and predictable.

          – Emad Salman
          Jan 22 at 5:29













          For example, Try calling myBoolValue.capitalize() from the example above on a server that hasn't been updated yet and you'll see 'System.UnexpectedException: Illegal arguments' in apex logs and internal server error on client. In any case, for 'String' arguments in particular, we have decided (in one of the upcoming patch releases) to update the new logic to accept number/boolean values and stringify them to mimic what users may have thought was happening originally :)

          – Emad Salman
          Jan 22 at 5:41







          For example, Try calling myBoolValue.capitalize() from the example above on a server that hasn't been updated yet and you'll see 'System.UnexpectedException: Illegal arguments' in apex logs and internal server error on client. In any case, for 'String' arguments in particular, we have decided (in one of the upcoming patch releases) to update the new logic to accept number/boolean values and stringify them to mimic what users may have thought was happening originally :)

          – Emad Salman
          Jan 22 at 5:41




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Salesforce Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f247438%2fvalue-provided-is-invalid-for-action-parameter-var-of-type-string-instead%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Probability when a professor distributes a quiz and homework assignment to a class of n students.

          Aardman Animations

          Are they similar matrix