rubenfiszel
commented
2 months ago Thanks for the feedback.
1) on debugging
- We will improve stack traces of normal exceptions
- There are 2 issues with debuggers:
- we can't make them work on the normal workers (because workers are meant to run jobs as fast as possible and having them being stuck on a breakpoint would be a giant waste of workers capacity), we would have to have a dedicated service for it.
- monaco (the code editor we use) has no support for breakpoint/debuggers so it's likely a lot of work to make it work. Another possibility is to actually popup a proper vscode-web in the debugger mode
2) on error handler:
- Yes, i'm not very happy with the state of the error handler. There are interactions that are probably wrong at the moment and please file bugs everytime you encounter them
- in most cases, the error handler should be used as a fallback or notifier. The one error handler that would be more practical is the setting "continue on error" of retries + branchone that catch the error case. This already work in the backend but the frontend/user experience of doing this is too heavy and we will improve it.
first off, i adore this product. and if any of this comes off as though i am annoyed or anything of the sort, absolutely nothing could be further from the truth. whether it's annoy-ing..., well... no one made you read it ;P. that is to say that i write this out of enthusiasm and boredom only.
i won't bury the lede: the real QoL improvement for error reporting/handling would be finding a way to make stack traces and the like even remotely usable. i understand that it is not necessarily a very easy thing to do. an absolute COUP, though, would be getting some sort of remote debugging in via chrome devtools or something that traps when exceptions get thrown. having just wasted far too much time fucking with docker on my self-hosted ee installation (don't tell my company that all their shit is running on a massive arch linux box in my office) before just giving up and adding a socat image to the docker-compose, i could understand a lack of enthusiasm on that front, but HOLY SHIT remove debugging against the web dev environment would go from zero to hero, just like that. and i genuinely don't think it would be that hard because, well, chrome devtools is awesome.
alternatively, another way to address it would be to make it a bit easier to handle the absolute morass of bun install / package.json this / python incumbent with running things locally. for all i know it is my own ignorance with build tools that is the architect of my own undoing, for despite somehow finding myself having to deal with them like half of the freakin time, i do not and will not ever understand them. i am simply not smart enough. needless to say, this route seems even harder than the first suggestion, but since one (or most likely many several) of you geniuses somehow managed to get all that hell working for the web experience / product in general, you'd surely be the right people for the job. hell, it might genuinely be the most impressive thing about the entire product, and i mean this completely unironically. there are some inevitable weirdnesses with stuff like syntax highlighting, etc. that comes from the way you do it that maybe could be improved a teensy bit, but it is damn impressive. it feels so fucking awesome to just be like "oh i'll just try this in a python lib" "oh i'll just copy paste in GraphQL from my frontend". amazing.
ok, now on to the mild shitposting. i like to think of myself as a fairly smart guy, but i couldn't tell you for the life of me what the error handler bug guy even, like does. and before you say "it's obvious", you should test out some of the interactions between it things like stop conditions set on for/while nodes and the like. i wish i could remember the exact situation i was in, but i sank a... let's just say good deal of time... into trying to figure out a way to keep my while loop stop condition working correctly while catching errors with bug catcher bro. i think i was returning just like {"error":} from buggy boy and the stop condition like refused to consider it an error or something regardless of whether i threw or returned the same {error: "blah"} shape as an error? all i know is that it heated my office up pretty good. it was either that or the exact opposite, because the (or at least my) solution was to wrap the offending script in its own special loop with the opposite settings from the outer loop. the ol
for(;;). and no, of course i didn't need to waste as much time screwing with it as i did-- that was entirely my fault, my depravity is my own fault and mine alone.on a similar note, afaict there's nothing you can do to capture the { error: "blah" } return value when it gets raised/skipped/bug catchered/etc., or at least not as far as i can tell. it even shows up with all the other data-bindable stuff like approvals, flow inputs, iter values, etc.-- another thing that works against our old friend Bug Catcher (almost as much as having to rock Caterpie and Metapod on his team). it seems to kind of work like the approval flow in terms of the values being special-cased, except that there is absolutely nothing you can do with it other than admire its red grandeur.