Pinging @U7ERLH6JX and @U0EHU1800

So I managed to quickly hack it together to make it work (listing buckets and putting an object successfully): I added a custom, static EndpointProvider implementation and cloned/hacked the definition of awyeah.client.api/client to use this new provider. Could look into providing a PR to: • support argument to client for letting the user override the endpoint-provider • add a “static endpoint provider” implementation to awyeah.endpoint that can be used in the same fashion thoughts @U0EHU1800? I’m not really an expert w/r/t the AWS apis, so I might be missing something in my approach here

yeah @U0EHU1800 would be a better person here than me

Hi @UHJQAD8BW My goal is to make awyeah-api have feature parity with aws-api. The aws-api (and awyeah-api) does provide :endpoint-override as you point out. As this is Cloudflare (and not AWS) it's possible that assumptions built into aws-api and its endpoint provider isn't compatible with Cloudflare. Can you provide a complete example of what you tried with the stock awyeah-api? Does it work with aws-api?

There isn't at the moment

It is possible to catch the existing exception and do it yourself though

Is there a way to do this across all tasks?

Without creating my own shell and exec...

(but yes I can do that)

I don't understand what shell and exec have to do with syntax coloring of code in the ex-info

I.e. in a file with 20 tasks rather than having 20 try/catch blocks...

again, what does this have to do with shell/exec?

I was thinking to create my own shell/exec with an internal try catch block... that would be clean. Sorry if that was confusing.

but not all tasks are just shell/exec?

You're right, the shell wouldn't work anyway... it would only be exec.

maybe a hook to do some processing after the uncaught exception has been handled would be nice, but so far there is nothing around it, feel free to write a proposal or something on Github Discussions

👍