Closed aiba closed 2 years ago
If I'm understanding this code correctly, L122 happens when the previous call to WriteInvokeResponse on L115 fails. So that indeed looks like an error case, perhaps to call babashka.WriteErrorResponse
.
But it looks like L130 occurs when the fs watcher hits an error, and in this case I think it'd be reasonable to just propagate that to the user's clojure code. I'm guessing the issue is passing a JSON string rather than a struct, since L117 passes the struct directly.
So I'm guessing L130 should be:
babashka.WriteInvokeResponse(message, Response{"error", path, nil, &msg})
Does that seem right?
Yeah looks like that to me too, feel free to raise a PR if you want, I can have a look at it! 😄
Closed in #13
Awesome, any chance you could cut a new release so I can stop depending on my local fix?
Sure. @lispyclouds Maybe we should take the opportunity to also bump the fs-notify dependency, etc, while we're at it?
Maybe bump deps in a branch first, to test if nothing breaks.
If @lispyclouds won't get to it, I can do this in the coming week somewhere.
I should be able to push something in by end of tomorrow hopefully
Thank you!
(I don't suppose there's a way to depend on a pod referenced by :git/url and :sha?)
Also available from the pod registry now. Thanks all!
I'm getting this stacktrace from fswatcher:
I think what's going on is that in the error cases,
event
is a string on this line:https://github.com/babashka/pod-babashka-fswatcher/blob/76403f153e6255e2ff0062dd9a909c9ec5b14738/watcher/ops.go#L177
And the call to
update
with a string argument causes the crash.It seems like this is because in error cases,
babashka.WriteInvokeResponse
is being called with a json string rather than aResponse
struct:https://github.com/babashka/pod-babashka-fswatcher/blob/76403f153e6255e2ff0062dd9a909c9ec5b14738/watcher/ops.go#L122 https://github.com/babashka/pod-babashka-fswatcher/blob/76403f153e6255e2ff0062dd9a909c9ec5b14738/watcher/ops.go#L130