Authorize some punctuation characters in connector function inputs and outputs?

Product Suggestions
1

Around the 31st of October 2024, I noticed on a customer’s instance that the character set allowed in connector functions’ input / output names had suddenly been severely restricted and limited to alphanumeric, spaces, underscores and dashes. Later, more characters were allowed again, notably letter characters of any language (with accents etc.).

That’s a progress to me, but I often find myself limited by not having access at all to characters as simple as (, ), [, ], <, >, ', " or :. It seems all punctuation characters (no matter the language / writing system) are now forbidden.

I’m aware that this is sometimes a matter of personal preference. But I find the ASCII ones useful to:

  • specify units: Weight (kg), Speed [m/s]…
  • specify datetime formatting required by third party systems: Production (YYYY-MM-dd HH:mm:ss)
  • specify general syntax required by third party systems: Serial (<batch>.<year>.<month>)
  • give some information about the value: Location ('FR', 'DE' or 'IT'), URL (prefixed with "https://")

I find the decision Tulip took surprising since this removes some freedom from users and enforcing this will not spare Tulip from having to deal with names already containing invalid characters in existing data (unless some escaping transparent to the final user occurred behind the scenes). What is the rationale behind this decision?

I think it would be nice to have some of these characters back. If not possible, having the ability to define and display a description for an input/output (especially when using the Run Connector Function action) might do the trick.

The root of the problem being that as an app editor, some users with no/little technical background or with a lack of understanding of systems interacting with Tulip might not know that some bugs can sometimes be caused by not adhering to a specific convention, e.g. on legacy systems. Putting some information in the name of the inputs/outputs is a simple way to remind the person of this if needed.

2

Hey @fti -

I was on the other side of this decission and I can share some of the rational here. You are totally right, that it is always a less than optimal experiece when you have access to something, then that access is removed - it is always perferrable to start with a more restrictive set of controls that we slowly loosen.

Historically this field had very very lo0se rules, even allowing things like emojis to be used in this field. This led to a number of super nasty bugs where inputs were not correctly interpolated into http calls correctly, or were interpolated in ways that were unexpected. the $ and . character have always been blocked for input names, but this list is actually inadequate to avoid all of the potential edges of interpolation. Characters like ()[]{} are all used used as part of payload building logic, and so allowing customers to use these (without a fairly massive refactor) created tons of potential failure modes that are very hard to surface to users.

As a shortterm stop-gap, we moved from “allow everything but X characters” to “Only allow X characters” to reduce all of these edges, before we can address a full refactor of how we do interpolation. We have done a few iterations to that list of supported characters (like you call out, with international characters, and more symbols). Let me go back to the team and see what we can do to further loosen these rules. Some of the characters you call out we should should be able to support.

Thanks for the patience -
Pete

3 Likes