Spotted another good example of “meh” error handling and abstraction leak in another topic:
This is a weird combination of mixed signals for non-technical users. I absolutely see why it’s like this, an HTTP 400 is a valid response for a “succesful” request, but for an end-user the thing they wanted to happen has failed. Activepieces doesn’t always recognize this properly, which can lead to even weirder behavior down the line.
I’d like to see Activepieces become much more vigilant in this type of error handling, i.e. fail-fast in programmer’s terms. Deployed flows ideally don’t receive attention from humans, so errors could currently easily go unnoticed for extended periods of time. Error handling and resiliency is already incredibly hard to get right for even experienced programmers, I’d love to move as much of this burden to Activepieces rather than the (non-technical) users.
The “output values” idea I mentioned earlier could help with this, since it creates a clear “expected value”, which makes it much easier to detect when something weird happens.
Like @Dennis said, please don’t let my flood of (hopefuly constructive) criticism get to you, Activepieces is already a solid product with tons of potential to become the greatest in its class!
I’d also like to mention again that it’s 100% my intention to actually help contribute to these things rather than functioning as the classic “idea man”, but unfortunately health issues are a limiting factor at this point in time.