I’m using SQL queries to communicate with Postgres databases. Sometimes, these will fail and result in a Tulip Player error message saying that the Connector has failed. I’d like to get these error codes.
I reached out to Tulip Support, and got the following back: “Postgres and other databases often have a variety of error codes and reasons for a single failure, and it could be quite an undertaking to translate and manage all of them into user-friendly error messages.”, which makes sense.
Originally, I had asked for the ability to return error messages similar to the HTTP Connectors. As this level of granularity is likely not feasible, I’d instead like to request the ability to perform an action / change a variable when a Connector has failed.
For example, I run a loop of values that are fetched from a given datetime onward. If one throws an error, I don’t want it to update my last datetime checked to now, as I will have missed that record (and without notice). Essentially, I want an error detected flag so that I won’t update my datetime checked (and will allow me to email, etc. someone in charge to remedy the issue).
I’m not 100% what this will look like (there are a lot of things in the works), but I’m open to discussion.
However, what you should always do is, clear the variable, the connector function result is meant to put in.
Then run the function.
Only deal with the result, if the variable is not empty.
That prevents writing wrong data, when connector function failed.
Let me check with the team to see if it is feasable to allow status codes to be mapped to outputs, much like we do with HTTP connectors so you can catch these cases. @thorsten.langner’s suggestion is a good one, and a common pattern we see across customers.
While I follow this principle for most cases, in these cases I’m writing data to a Postgres table (so no return value).
If it’s an update write, then I’d need to also introduce a date modified (or similar) for a follow-up check to make sense, which is more overhead than I’d like.
100% agree that that’s how things should be handled when you’re returning data, but the alternative (posting data) is a different story.
Was searching for something else here and came across this post. @Preston if you can move your queries into postgres functions internal to your database and use procedural language, you can benefit from some built-in error handling. My team has been doing this for the last few months with good results. You can see an example of what I mean at Postgres 17 | db<>fiddle
We build all of our write functions this way now, and the output of our write connector functions include result_code and result_message. We then output this to a variable in the app (after first clearing it before running the connector function), and build trigger logic downstream of the connector function call to check result_code. If it’s a 1, great, keep going, if it’s anything else, get as creative as you want to show feedback to the user etc. So far we just pop up an error message to the user with result_message SQL error returned and that’s already been very helpful in end user troubleshooting. You can also see in the dbfiddle example above that this lets you build your own custom error messages and other data validation mechanisms.
I know this is an older post but hope someone else finds this helpful!