attribute_not_exists not respected consistently

[ricardojmendez]

Just ran into some odd behavior. It might be a bug, or it might be a

  ;; attribute_not_exists is evaluated even on range keys
  (expect
    #=(far/ex :conditional-check-failed)
    (do
      (far/put-item *client-opts* range-table {:title "Three" :number 33}
                    {:cond-expr "attribute_not_exists(#t) AND attribute_not_exists(#n)"
                     :expr-attr-names {"#n" "name"
                                       "#t" "title"}})))

  ;; attribute_not_exists is respected even if only the condition covers only one of 
  ;; the two values
  (expect
    #=(far/ex :conditional-check-failed)
    (do
      (far/put-item *client-opts* range-table {:title "Three" :number 35}
                    {:cond-expr "attribute_not_exists(#t)"
                     :expr-attr-names {"#t" "title"}})))

The first test pass, the second test fails sometimes. Not sure why. If it always failed I could chalk it up to a misunderstanding of what the conditional checks for.

It's not just a testing issue, or bad behavior on the part of DynamoDBLocal. I was writing up the tests because I tripped this behavior on an application. Tried it both against local and against a live instance.

[langford]

I ran into this as well...you are right, it might just be local. I rewrote the update tests to not re-use one another's data and it continues to fail every time on local

[kipz]

@ricardojmendez @langford I've tried to recreate what you're describing above, but I've not found anything unexpected yet:

https://github.com/Taoensso/faraday/commit/a644735265b039214507b0a8ec8756cfa3fe9780

Perhaps I didn't get the pre-conditions for the tests right?

FWIW - faraday just passes the cond-expr through to the underlying Java library, so whatever we have here, it's likely not a faraday issue.

[kipz]

Given the above, I think we should close this. Please reopen if you disagree.