i don't think tx-range is producing the clojure.lang.Delay in onyx-datomic. at least I can't seem to repro, though if I run my onyx job it repros every time. still digging but not sure where to start. currently throwing a ton of log statements in onyx-datomic.

@devth it’s such a weird one. I am pretty sure it’s coming from somewhere in datomic though.

we certainly don’t use delay in onyx

ok. the reason I don't think it was is because I started logging params used to call tx-range, e.g.:

tx-range 7174
tx-range 7560

7560 appears to be near the very end (only about 10 datoms after that point)

i can run tx-range in a repl with 7560 and it gives me back a seq of datoms

My guess is that there’s just some code path that will return a delay inconsistently

i opened a support issue with the datomic team but they need a repro

currently i can only repro by running the job. not via my repl

does core.async ever produce a delay?

Can you paste the stack trace again?

You’re using onyx 0.9 still, right?

yep

k, one sec. will come up with a version of onyx-datomic that you can try

@devth can you try to make it happen with onyx-datomic 0.9.15.1-20170518.234522-2?

yep

It immediately tries to serialize the segments fetched from tx-range

then it will print them if it can’t

[idx-2848043163-77jsn idx] ERROR COMPRESSING TXRANGE ENTRIES
[idx-2848043163-77jsn idx] ({:id #uuid "591a05cc-9a78-4005-84f3-fad2cf9694da", :data #object[java.util.Arrays$ArrayList 0x2b76db59 

followed by a ton of datoms and ArrayLists

top level exception is Unfreezable type: class java.util.Arrays$ArrayList

Ah actually I should try and unroll it first. One moment - I’ll get you another version

Can you try 0.9.15.1-20170518.235538-3

yep

it's in the pipeline. uberjar: 1.5 min build and push docker image: 1.5 min deploy: 20 seconds