I shipped a production bug today because I forgot to remove a workaround I needed to have the Elm debugger not break

Request Feedback
1

There’s an issue with the Elm debugger where it breaks when a large list is fetched. The project was started a year ago and the issue did not happen then because the list the API returned wasn’t that long then. I came back for some additional features recently and ran into this issue debugger runtime exception: Uncaught RangeError: Maximum call stack size exceeded · Issue #2133 · elm/compiler · GitHub (seems to be only breaking in Chrome)
Since I could develop locally otherwise, once I tracked down that it was the size if the list that caused the issue I adde a List.take 10 before my usage of the list, which made the list small enough for the debugger to work.
I made a TODO comment to remove this logic before shipping to production, would up forgetting :man_facepalming: and the bug ended up in front of users on prod. Of course that is my fault.

Today I was reminded of the bug another time by megapctr on slack who asked around because of the same issue.

Several people have posted about this: Maximum call stack size exceeded when running --debug · Issue #90 · elm/browser · GitHub, here’s a PR Fix stack overflow when operating on large lists by robinheghan · Pull Request #95 · elm/browser · GitHub and some others that I don’t find right now. Anyone else ever ran into this? Is this affecting your local development badly?

2 Likes
2

Small workaround: If your setup allows (or can be made to) do --optimize builds for production, you could put a Debug.log nearby. Then the production build will fail if you forget to remove the hack.

1 Like
3

@evancz Please merge the PR, its a small fix to make iterating over the list tail recursive, should only result in a minor version bump on elm/browser.

11 Likes
4

Not that it will help for this time, but you can use NoForbiddenWords - elm-review-forbidden-words 1.0.1 to prevent shipping code containing specific comments.

For instance, you could configure the rule with DONT PUSH, FIXME or something similar (even TODO could work unless you already have plenty) and then as long as you have elm-review enabled in CI, you will be reminded to remove your change before it’s pushed out to production.

9 Likes
5

There are actually at least three reports of this issue, and two proposed fixes. I have now linked them all together. Hopefully that’ll help emphasize the importance of the issue and decide which of the two fixes is better.

3 Likes
6

I have an open issue in elm-explorations/test on what is likely the same underlying problem, although in this case it isn’t tied to the debugger: Yet another Maximum call stack size exceeded error (with Expect.equalLists) · Issue #123 · elm-explorations/test · GitHub. The fact that the test package will reliably crash is in turn preventing me from submitting a pull request on another package, because I can’t write the test that will demonstrate the fix.

It’s been so long that I can’t even remember which package I was going to submit the pull request to.

1 Like
7

I also have run into this bug.

The trust in the language is greatly affected if bugs are not fixed.

3 Likes
8

Seem that fix just considering the Debugger and its expansion rather than the List itself. Or is that the problem - that Debugger is triggering that error rather than the List? Then not using the debugger should help, right?

9

Yes, the bug is in the debugger code so that is a workaround. Sounds like there was a production problem for the OP, but not a showstopper with regard to getting a fix into Elm for it.

1 Like
10

Oh it is stated in the first sentence. :man_facepalming: I have to read the stuff thoroughly next time :slight_smile:

11

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.