<kares[m]> so it's only happening on master with Rails 7, right?
<headius> Back at it today
<enebo[m]> kares: yeah and only running unit tests so far but our log method is picking up binds kwargs as an array
<enebo[m]> def log(sql, name = "SQL", binds = [], type_casted_binds = [], statement_name = nil, async: false, &block) # :doc:
<enebo[m]> def log(sql, name = "SQL", binds = [], type_casted_binds = [], statement_name = nil)
<enebo[m]> yeehaw
<enebo[m]> So sqlite3 will not have this issue but all callers of log in other adapters must also have async above it
<enebo[m]> I suppose I will commit anyways for now
<headius> Incrementally better is still better
<enebo[m]> headius: and since we use some percentage of AR for pieces in adapters it is likely other adapters will be calling this the right way
<enebo[m]> in places and not in others
<enebo[m]> I am still a bit mystified that the error gets swallowed and tests still pass
<headius> Perhaps it is expecting some other error and casting too wide a net
<enebo[m]> yeah I mean it must but I don't see where
<enebo[m]> It not being valid is fine in that sense it would not affect something...but it gets caught
<enebo[m]> and the confusing bit is it stores those binds into a lambda and validates them at a later time
<enebo[m]> anyways it probably is not really worth figuring out. It is definitely worth it for us to run with exceptions on here and there though
<enebo[m]> err I mean above that gettign [:async, false] could never respond to whatever it thinks it should happen so it will say no binds and technically there are no binds there
<enebo[m]> .2022-05-26T09:01:44.868-05:00 [main] INFO TraceType : Exception raised: NoMethodError : undefined method `to_i' for #<ActiveRecord::StatementCache::Substitute:0xdcfd5eb>
<enebo[m]> LOL. Also no error and it only happens a few times
<headius> ok Fiber#raise starting to work
<headius> 1 file, 29 examples, 37 expectations, 2 failures, 2 errors, 0 tagged
<headius> Fiber#raise specs... the remaining cases are a little edge-casey like raising in a fiber that hasn't started yet or some edge case ArgumentError conditions
<enebo[m]> nice
<headius> bleh this logic is so nasty
<headius> I am wondering if we try too hard to handle exceptions at the edges and that's why Fiber#raise was added
<headius> I am trying to marry our existing propagation of exceptions up a fiber chain with this new logic that has to propagate such exceptions differently
<headius> normally if a thread receives an exception while waiting on another fiber, the exception is re-raised in the fiber to see if it wants it... but if the fiber raised it in response to Fiber#raise it should propagate up out of the thread immediately
<headius> there's some extra state transitions I'm missing here to know what to do with the explicitly raised exception
<headius> bbl
dangerousdave has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dangerousdave has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<byteit101[m]> headius: ah you are back! when did you want to post my blog post?
dangerousdave has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]