Fork me on GitHub
#re-frame
<
2023-07-04
>
hifumi12302:07:13

I am suddenly getting the following error with re-frame-10x. Has anyone else faced this before?

#error {:message "Set literal contains duplicate key: ["app-db-path" nil 0 0 0 ...]" 
        :data {:type :reader-exception 
               :ex-kind :reader-error}}
This happens when loading =frame-10x.preload

p-himik06:07:10

Is there a stacktrace? And which version of re-frame-10x?

hifumi12307:07:11

No stack trace, both 1.6.0 and 1.7.0. What's weird is that Chrome ran into this issue, so I switched to Firefox for dev, and now Firefox has this exact same issue

p-himik08:07:38

Huh? How come there's no stacktrace? Where exactly do you see that error? In the JS console of your browser it should be an expandable object with a stacktrace.

p-himik08:07:38

Ah, that's interesting. My crystal ball is sparkling. :) Do you have *print-length* set? To 5, perhaps.

p-himik09:07:34

That's the culprit. That vector in the error is a path that gets written to local storage. re-frame-10x naively uses pr-str which breaks when you specify print length. A proper fix would be for re-frame-10x to use a more reliable serialization approach. A local fix that you can do is to avoid setting *print-length* globally. And to fix your browsers, you need to erase the local storage keys related to re-frame-10x.

hifumi12311:07:11

Oh wow, I would’ve never guessed this. I will follow these suggestions “tomorrow” and report back. Thanks for the guidance

👍 2
hifumi12312:07:32

ok out of impatience I decided to try your suggestions right now, and they indeed fix the problem on my end. I can't reliably reproduce the bug though

p-himik13:07:30

I'm not sure what that path is so can't describe how the issue should be reproduced. Perhaps it's' to store which paths are expanded when viewing app-db in the re-frame-10x panel. If that's the case, you have to expand more than 3 separate paths and maybe close/open the panel and maybe refresh the page.

Kimo20:07:39

Hey, if anyone managed to reproduce this, I'd appreciate if you could test out my branch. https://github.com/day8/re-frame-10x/pull/396 I'm on the fence about it, so I'd like to know more. Is it just because you mutated *print-length* globally? Is that a conventional thing to do? Seems like it risks breaking more than just re-frame-10x. For instance, both reagent and garden use pr-str in various places.

hifumi12321:07:00

I don't use garden and I cant recall reagent breaking to this. The reason to set *print-length* is quite simple: you're at a REPL dealing with large or infinite lazy sequences and dont want to flood your whole buffer. It's a very normal thing to do and the var exists precisely for this purpose

hifumi12321:07:49

in jvm clojure, this issue doesnt exist because objects implement the Serializable interface, so people will not depend on pretty printing behavior to store objects on disk (even then, most people end up using nippy since its a more convenient binary format)