Renaming Postgres step parameter causes Data Mapper issues

This is a…

[ ] Feature request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Documentation issue or request

Description

If the SQL query in a Postgres step is changed so that an existing :# parameter is renamed, and when that particular parameter was already mapped in a previous Data Mapper step, a data type mismatch warning is shown on the Postgres step (understandably, since the input data changed). Opening the Data Mapper step shows an error about missing field (again, understandable). However, changing the mapping from the old to the new field name does not make the mismatch warning go away. In fact, the only way to make it go away is to rename the parameter back to its old name (a nuance here is that after renaming to the old name, no warning is shown, even though the mapping now references a non-existent parameter, with the new name).

Not sure this is only happening with the Postgres step, haven’t tried any other.

Steps to Reproduce

1. Create a new API Provider from the Todo API, start implementing the Fetch Task operation
2. Add a Postgres step, set the SQL to SELECT * FROM todo WHERE id = :#id
3. Add a Data Mapper step between the start and Postgres steps, map id to id
4. Open the Postgres step again, change the :#id to something else
5. Observe the data type mismatch warning
6. Try to fix the mapping

Screenshots

[heiko-braun]

Not for 7.2, but we can explore the UX approaches in the 7.2 time frame and aim for implementation changes in 7.3

[gashcrumb]

Yep, in this case you just need to delete the data mapper step after changing the type, then add a new data mapper step. So I wouldn’t call it a blocker.