This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-12
Channels
- # aleph (3)
- # announcements (7)
- # babashka (22)
- # beginners (44)
- # calva (19)
- # chlorine-clover (1)
- # cider (20)
- # clj-kondo (55)
- # clojure (100)
- # clojure-austin (9)
- # clojure-europe (19)
- # clojure-italy (19)
- # clojure-nl (13)
- # clojure-portugal (2)
- # clojure-uk (7)
- # clojurescript (38)
- # community-development (3)
- # conjure (2)
- # cryogen (57)
- # cursive (6)
- # datalog (3)
- # datomic (24)
- # emacs (17)
- # exercism (8)
- # fulcro (3)
- # holy-lambda (8)
- # jobs (6)
- # jobs-discuss (9)
- # joker (3)
- # lambdaisland (5)
- # leiningen (5)
- # music (9)
- # nextjournal (1)
- # nrepl (2)
- # off-topic (9)
- # other-languages (4)
- # pathom (6)
- # polylith (23)
- # re-frame (5)
- # reagent (5)
- # remote-jobs (1)
- # reveal (1)
- # shadow-cljs (3)
- # tools-build (1)
- # tools-deps (3)
- # xtdb (2)
is it possible / adviceable to return a success http repsonse immediately and continue doing work in the lambda?
Nope.
What you would like to do after sending the http response?
It was just that gitlab said it should return true and quick. But yea I can just do all my work and then return
If you're doing something that is async/requires fault tolerancy consider using sqs
i was considering sqs for that use case, but I think a Cloudwatch log filter would be better since it’s simpler - log a message describing what you want to do and have a lambda that runs by reading that log message and doing whatever is needed: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html#LambdaFunctionExample
Yeah. But still it's hard to handle retries that way.
that’s true, something to keep in mind