Lazy recursive decoding error when using multiple modules

[lsjroberts]

I'm not entirely sure what is causing this issue, or if it'll be reproducible on another machine but please let me know.

Clone this repo - https://github.com/lsjroberts/elm-recursive-decode-issue

Then run elm reactor.

If you go to http://localhost:8000/MainSplit.elm and open the console you will see these errors:

Now go to http://localhost:8000/MainBundled.elm and open the console, and you will see no errors and the decoded model logged out.

The only difference between the bundled and split versions is that the types in Split/Types.elm are bundled together in Bundled.elm at the bottom of the file.

Curiously, if you do the same with Split/State.elm and leave the import of Split.Types at the top you will not see any duplicate definition errors and the program will now work!

---

The issue appears to stem from the manuscripts field in the model. If you remove this from the model and update the metaData decoder to the below it will work:

metaData : Decoder Model
metaData =
    map6 Model
        (field "name" string)
        (field "author" string)
        (field "plan" (list file))
        (field "notes" (list file))
        (field "open" (list file))
        (field "active" (nullable filePath))

So I can only assume it is related to the lazy evaluation of the recursive type decoder fileChildren.

If I could hazard a guess it'd be the evaluation time differs when running it between two modules.

I have tried using NoRedInk/elm-decode-pipeline but this does not support recursive type decoding. And using the elm-lang/lazy module did not seem to make any difference.

---

Apologies if the code is a bit messy, I've been extracting it from my app to try to narrow down the culprit.

This is a weird one. I have seen this issue in two independently created elm 0.18 projects while testing. Please let me know if you are unable to reproduce it.

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[lsjroberts]

I'll try and reduce the size of the example to help.

[lsjroberts]

I'll try and reduce the size of the example to help.

[jvoigtlaender]

This suspiciously looks like existing open issues in the elm-compiler repository.

In any case, given your hunch that tge problem is one of lazy evaluation and recursion, it's much more likely a compiler problem than a library problem.

So it should be moved over to that repository (probably after checking tge open issues there whether it's indeed very similar to something already reported).

[jvoigtlaender]

This suspiciously looks like existing open issues in the elm-compiler repository.

In any case, given your hunch that tge problem is one of lazy evaluation and recursion, it's much more likely a compiler problem than a library problem.

So it should be moved over to that repository (probably after checking tge open issues there whether it's indeed very similar to something already reported).

[jvoigtlaender]

I was thinking of elm/compiler#1560.

[jvoigtlaender]

I was thinking of elm/compiler#1560.

[lsjroberts]

Ah apologies, that didn't come up in my searches. Thanks.

[lsjroberts]

Ah apologies, that didn't come up in my searches. Thanks.

[lsjroberts]

To confirm that is definitely the same issue, reversing the order of my decoder definitions fixed it. Thanks again!

[lsjroberts]

To confirm that is definitely the same issue, reversing the order of my decoder definitions fixed it. Thanks again!