For my solution to Difference of Squares in the Gleam track, iteration 2 is stuck in “processing” mode. This happened for iteration 1, so I deleted it, made a minor change to my code (otherwise, resubmission isn’t possible), resubmitted my solution, but now iteration 2 is also stuck in “processing” mode.
My suspicion is that I named a function parameter the same as the name of a module I imported. While this is perfectly valid Gleam, and all tests pass locally, given my suspicion that this is the source of the “processing” problem on the site, I renamed my function parameter such that it is not the same as the name of an imported module (and made no other change), resubmitted my solution, and iteration 3 did not get stuck in “processing” mode.
I’ve left iteration 2 in place so that whoever looks into this bug can compare iterations 2 and 3 to see the only difference is the name change, and also to perhaps see why iteration 2 is still “processing.”
Obviously worth working out why this is happening (cc @lpil)
The fact it’s stuck in processing mode is weird. It should be “exceptioned”. That suggests to me that either Exercism’s website isn’t getting back any response about this (which means something’s blowing up at the orchestrator level) or is failing to deal with the data that’s coming back from the test runner in quite an extreme way. We should try and work that out and patch that bug, but also that points in my mind to a possibly invalid JSON in the results.
So there’s likely both a Gleam issue and a code-infrastructure bug for you to investigate.
The solution is valid Gleam, and it works if I submit it as a solution on the website myself, so I suspect this is some form of transient error in the build environment.
It seems that way. I have also seen one of my Gleam submissions get stuck in “processing”. I deleted the iteration then resubmitted the same code, and it worked.
