Value provided is invalid for action parameter [VAR] of type 'String'" instead
Clash Royale CLAN TAG#URR8PPP
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
asked Jan 21 at 19:59
Andre TheriaultAndre Theriault
635
add a comment |
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
asked Jan 21 at 19:59
Andre TheriaultAndre Theriault
635
add a comment |
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
asked Jan 21 at 19:59
Andre TheriaultAndre Theriault
635
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
apex lightning aura spring19
asked Jan 21 at 19:59
Andre TheriaultAndre Theriault
635
asked Jan 21 at 19:59
Andre TheriaultAndre Theriault
635
edited Jan 21 at 20:12
Andre Theriault
asked Jan 21 at 19:59
Andre TheriaultAndre Theriault
635
asked Jan 21 at 19:59
Andre TheriaultAndre Theriault
635
asked Jan 21 at 19:59
Andre TheriaultAndre Theriault
635
635
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
answered Jan 21 at 20:25
sfdcfoxsfdcfox
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
|
show 3 more comments
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
answered Jan 21 at 20:25
sfdcfoxsfdcfox
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
|
show 3 more comments
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.
answered Jan 21 at 20:25
sfdcfoxsfdcfox
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
|
show 3 more comments
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.
answered Jan 21 at 20:25
sfdcfoxsfdcfox
254k11198438
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.
answered Jan 21 at 20:25
sfdcfoxsfdcfox
254k11198438
answered Jan 21 at 20:25
sfdcfoxsfdcfox
254k11198438
answered Jan 21 at 20:25
sfdcfoxsfdcfox
254k11198438
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
|
show 3 more comments
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
|
show 3 more comments
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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