How to modify expression rule without break compatibility

This type of scenarios can be prevented using label value pair while calling the expression rules.
For e.g. rule!rule_name(param1Label:param1Value, p2Label:p2Value)
This way, when you add another parameter to your expression, it take null value by default and the 'incorrect number of param' exception gets handled.
Ofcourse- you need to handle null pointer exception in rule definition..

Unfortunately I was not using label value pair when calling the expression rule :( I guess I have to create new expression rule in my scenario.

Yes, I am afraid.
The measure, I described is preventive and not curative. I suppose your application is live hence you are skeptical to change the process model.
Please follow above measure as well as creating unit test cases to ensure your expression rules are stable for future changes.

You can create a new expression and make the old one call the new one with some default values for the missing parameter. This way you do not have to maintain two expressions.

i do not think even using label value pair will handle this because you are adding a parameter to your rule.

@sparashs It will work. If you use label-value syntax and add a parameter to a rule, all existing rules will just pass in a null as the newly added parameter.

ok yes i agree. I actually misunderstood the question.

yes, @joshl is correct, this use case is one of the largest examples of why to use dictionary syntax (ie label-value) when calling expression rules.

@amirh Just to keep things simple, afaik the approach mentioned by @tajinders is called 'by keyword' approach and the approach you have used in your process model is called 'by position'.

There are two ways to resolve the issue as per my experience in working with in-flights:

1. Use the same old expression rule and work on in-flights:

a. Upgrade the version of those processes(that made use of 'by position' approach) to the one that makes use of 'by keyword' approach. You may study this by analysing the process details(along with their process model version) report. This is bit tricky as you need to make sure that the upgraded processes won't pick up the new nodes or features added in the new versions. If there are many instances, and various instances at various levels in the process and huge changes in the recent versions of the process model, it's really time consuming to design the in-flight modification. Once you are done with this step, the instances that haven't hit the node making use of the rule (which you have mentioned) will be cured.
b. Idenitfy those processes that has got their node cancelled because of this issue. Using a Shared Component target the failed node in the identified processes, cancel the node and restart the node. (Use the 'Restart All Nodes' from 'Process Management Services' plugin. Though the name convey 'All', I belive ít has got the capability to function based on the for a given node uuid and process id.) Post completion of this step, the failed instances should be able to recover.

I could say that this approach needs a lot of investment of time in analysing the existing processes, new features in the to-be upgraded version and how existing processes picks up new features and so on. Also this needs reproduction of the scenario, with the instances of those versions that are exactly available in prod. Most important thing is, if you are dealing with production data you need to be lot more careful. I wouldn't say that it's ompossible but it needs thorough knowledge of existing processes as well as changes.


2. Approach as specified by @stefanh or your thoughts over creating a new expression rule.

But I have seen some people arguing that 'by keyword' approach isn't great and prefers to go with the creation of new versions(by appending v2,v3 and so on.) of rules upon change in the definition(i.e. inputs). Their idea is that we don't need to really end up in complicating the rule upon handling the missing inputs over the time.

I would personally encourage to use 'by keyword' approach.

Keyword or "label-value" is certainly preferable. Besides being more "change-proof", it also has better readability. You will need to type the parameter names and their values(and some may frown by saying that it takes a lot of typing), but the advantage is anyone who is reading the code later knows what parameter is taking what value.
Passing parameters by keyword makes it very explicit, reduces the chances of errors. Imagine passing parameters by position, and let's say some other developer removes a parameter. Any rules you created that are dependent on the rule which changed will cause errors in your rules also.
A point that you should keep in mind - Although passing parameters by keyword is a good practice and preferable, custom plugin functions do not support it. But expression rules created in Appian do support the keyword syntax.