You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We just recently upgraded serde, and we're seeing the effects of #2566 being merged in. We use serde for REST APIs, and often if we rename a field, we keep the old field aliased to the new field, only for people who are already integrated in the API.
We surface serde error messages if users input wrong fields, but after this change we are now also showing the user all the "deprecated" aliases that we don't want them seeing.
I would imagine that this isn't an uncommon usage for the "alias" attribute, i.e. to map existing names to a field, while having a new canonical name.
Would you be willing to consider reverting #2566, or consider a hidden attribute to the alias, determining whether or not aliases show up in error messages?
The text was updated successfully, but these errors were encountered:
Hi!
We just recently upgraded serde, and we're seeing the effects of #2566 being merged in. We use serde for REST APIs, and often if we rename a field, we keep the old field aliased to the new field, only for people who are already integrated in the API.
We surface serde error messages if users input wrong fields, but after this change we are now also showing the user all the "deprecated" aliases that we don't want them seeing.
I would imagine that this isn't an uncommon usage for the "alias" attribute, i.e. to map existing names to a field, while having a new canonical name.
Would you be willing to consider reverting #2566, or consider a
hidden
attribute to thealias
, determining whether or not aliases show up in error messages?The text was updated successfully, but these errors were encountered: