17

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).

Improve this question

1 Answer 1

Reset to default
11

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.

Improve this answer
8
  • 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
    Commented Jan 21, 2019 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 ♦
    Commented Jan 21, 2019 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
    Commented Jan 21, 2019 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
    Commented Jan 22, 2019 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
    Commented Jan 22, 2019 at 5:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .