SQS :SendMessage results in a :cognitect.anomalies/fault

[jdhollis]

Running into a strange issue with the SQS library—

The messages are being successfully sent, but I’m getting a :cognitect.anomalies/fault (which is throwing off my error handling):

{:cognitect.anomalies/category :cognitect.anomalies/fault,
 :cognitect.aws.client/throwable #error {
 :cause "clojure.data.xml$parse"
 :via
 [{:type java.lang.NoClassDefFoundError
   :message "clojure/data/xml$parse"
   :at [cognitect.aws.util$xml_read invokeStatic "util.clj" 137]}
  {:type java.lang.ClassNotFoundException
   :message "clojure.data.xml$parse"
   :at [java.net.URLClassLoader findClass "URLClassLoader.java" 382]}]
 :trace
 [[java.net.URLClassLoader findClass "URLClassLoader.java" 382]
  [java.lang.ClassLoader loadClass "ClassLoader.java" 424]
  [java.lang.ClassLoader loadClass "ClassLoader.java" 357]
  [cognitect.aws.util$xml_read invokeStatic "util.clj" 137]
  [cognitect.aws.shape$xml_parse invokeStatic "shape.clj" 214]
  [cognitect.aws.shape$xml_parse invoke "shape.clj" 214]
  [cognitect.aws.protocols.query$build_query_http_response invokeStatic "query.clj" 110]
  [cognitect.aws.protocols.query$build_query_http_response invoke "query.clj" 103]
  [cognitect.aws.protocols.query$eval1712$fn__1713 invoke "query.clj" 116]
  [clojure.lang.MultiFn invoke "MultiFn.java" 239]
  [cognitect.aws.client$handle_http_response invokeStatic "client.clj" 48]
  [cognitect.aws.client$send_request_STAR_$fn__11422 invoke "client.clj" 80]
  [clojure.core.async.impl.channels.ManyToManyChannel$fn__3442$fn__3443 invoke "channels.clj" 95]
  [clojure.lang.AFn run "AFn.java" 22]
  [java.util.concurrent.ThreadPoolExecutor runWorker "ThreadPoolExecutor.java" 1149]
  [java.util.concurrent.ThreadPoolExecutor$Worker run "ThreadPoolExecutor.java" 624]
  [java.lang.Thread run "Thread.java" 748]]}}

My invocation is pretty basic (and more or less the same as I’m using everywhere). And since the messages are getting sent to the proper queue, I'm guessing that's not the issue.

(def ^:private sqs
  (delay (aws/client {:api :sqs})))

(aws/invoke @sqs
            {:op      :SendMessage
             :request {:QueueUrl    api-key-creation-queue-url
                       :MessageBody (:hashed-email registration)}})

I'm also running the latest version of everything:

{:deps    {org.clojure/clojure                {:mvn/version "1.10.1"}
           com.amazonaws/aws-lambda-java-core {:mvn/version "1.2.0"}
           com.cognitect.aws/api              {:mvn/version "0.8.408"}
           com.cognitect.aws/endpoints        {:mvn/version "1.1.11.682"}
           com.cognitect.aws/sqs              {:mvn/version "770.2.568.0"}
           …}}

Any ideas?

[jdhollis]

Ah. This seems related to #86. For the record, I'm running this on Lambda with the java-1.8.0-openjdk runtime.

[jdhollis]

Actually, after digging around for a few hours, I suspect this has something to do with how our uberjar packager is handling transitive dependencies.

Closing for now.

[dchelimsky]

It makes sense that it's a transitive dep issue. Please do report back here if you find a workaround so other ppl can take advantage of it. Thanks!

[jdhollis]

Turns out this is a known bug in luchiniatwork/cambada: luchiniatwork/cambada#16

I've created a fork that meets our needs for the moment: https://github.com/jdhollis/cambada

That said, I'll be keeping an eye on (and possibly contributing to) @luchiniatwork's master version.

[dchelimsky]

Thanks for the sleuthing and follow up @jdhollis.

[gozes]

So I'm running even more up to date versions of everything but I'm still getting this issue

                 [com.cognitect.aws/api "0.8.469"]
                 [com.cognitect.aws/endpoints "1.1.11.837"]
                 [com.cognitect.aws/ssm "807.2.729.0"]
                 [com.cognitect.aws/sqs "801.2.702.0"]

[jdhollis]

@gozes Are you running via an uberjar? If so, how are you packaging it up?

[gozes]

@jdhollis so I am building an uberjar just by running lein uberjar in my CI pipeline. on my project.clj I have

  :uberjar-name "cloudservice.jar"
  :aot :all
  :main dwh2-receiver.core)

so nothing special

[jdhollis]

I would check Lein's issues then. I haven't used Lein in a while, but the issue I was running into was related to transitive dependencies.