I've just tried building arrow locally. Everything but one test passed: `> Task :arrow-free-data:...

# arrow-contributors

[Attila Domokos]

I've just tried building arrow locally. Everything but one test passed: > Task :arrow-free-data:test FAILED with latest commit.
Using Mac OS 10.14.6, using Java 8.0.232.j9-adpt.
I tried to look at the build server, but couldn't find the latest build.
Is this expected? If not, what could I do to make this test pass?

[raulraja]

Is this something you can reproduce consistently? It may be just a flaky test in which case the way to proceed is an issue. @Jannis was recently changing the way stack safety impacts in ap and perhaps in foldables and this may be related

[Jannis]

I'll take a look, but I doubt it because cofree has been unchanged for quite a while. That being a flaky test would also be weird as it tests a recursive function over 10k steps 🤔

[Jannis]

It is a bad test though: It tests something that is a side-effect of the platform running it. Stack-unsafety should not be tested at all. Stack-safety is a feature we offer with some datatypes so it should, but the reverse is not true. I mean whats wrong if the jvm could suddenly exectute it stacksafe anyway... Either way, it passes for me and the code that is being run and also the datatype have not been modified the last year. @Attila Domokos I am running on linux with almost the same version from openjdk and could not reproduce it. If it keeps happening let me know and I'll probbly just add a pr to remove this test for the reasons outlined above

[raulraja]

Maybe it's a diff in the JVM stack size setting, If I recall we jump after 127 frames

[Jannis]

That should be correct (at least thats what AndThen does which I've recently looked at). But this test does not check stacksafety, it checks for stack-unsafety of Cofree.run with Option as the functor. And that is pointless imo.

[raulraja]

Yes option is not stack safe on any of it's ops

[Attila Domokos]

Yes, I can reliably reproduce this test failure on my computer.

[Attila Domokos]

I've just pulled latest and ran the tests 3 times. The first and second run had this mtl test failure. The 3rd one had the CofreeTest.

After running all the tests ~20 times, I have not had a successful test run, only 1 test failed always, either this mtl one or the CofreeTest.
Hth.

[Jannis]

The mtl one is worrying, the cofree one does not matter I think. Either way this is weird. I'll look at the mtl one later today, as that should not be happening

[Attila Domokos]

I can provide better stack traces if that helps.

[Jannis]

Damn, I got that stackoverflow the first try as well. Nice catch ^^ I'll have a look and try to fix it. It's weird tho, because ci etc all ran fine. It is also old code, both Kleisli and the test have not been changed for about a year, so it's pretty random to see it now.

[Jannis]

I think kleisli needs the same treatment as StateT with AndThen

[Jannis]

It's stacksafe with AndThen but I could not convert every combinator on Kleisli. But that is definitly an issue. Will create a pr tomorrow, and I'll also remove the cofree-stackunsafety test...