@borkdude I think I figured out what I'm running into with these test failures in the instaparse pod. On the client side, the class instaparse.gll.Failure doesn't exist. And when I try to create it w/ a defrecord I get a sci.impl.records.SciRecord instance of course. So that means the client's Transit write handler (which is matching on instaparse.gll.Failure) doesn't get triggered. Is there something I can create in the client that can trigger the Transit write handler? The instaparse code for failure? is just checking for instances of that class, so if I can trigger the Transit write handler and get the correct tag on it, the pod will turn it back into an instance of the correct class.
For example, if I could trigger a Transit write handler on the SciRecord named instaparse.gll.Failure, that should fix it. But I'm not sure how / if that's possible.
couldn't we just represent the failure object as a map with failure true or so? and then we just change this function here?
https://github.com/babashka/instaparse-bb/blame/main/src/instaparse/core.bb#L89
is this one safe to merge? https://github.com/babashka/instaparse-bb/pull/11/files
oh, yeah, so like wrap the result instead of the old assumption that it was a map? hmm, yeah, that could work.
OK, I have something working here that makes all of the test suites happy. Will PR shortly.