Cfrgtkky

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

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.