Untitled attachment

@mint Like, I can't actually use this API as-is because it's for shipping JSON around and it silently discards other parameters if you upload a file and it only lets you upload one (so much for the "multi" part of "multipart"): https://git.freespeechextremist.com/gitweb/?p=fse;a=blob;f=lib/pleroma/http.ex;h=052597191fcc90d48641217f6002418462893031;hb=HEAD#l61 . So I have to take a step down and just talk to Tesla and build the multipart request myself if I'm trying to make something you can drop into Pleroma instead of something that requires changes to Pleroma; fine, I don't mind, this is called "programming", I can do that.

Tesla returns `{:ok, {status: whatever}}` as long as the request succeeds, and then you handle the status being 200 or 201 or 401 or what-have-you. That's sensible, that's what you want, you want the client library to tell you that there was an error if the server couldn't be reached or if it responds with non-HTTP shit and that it was fine as long as the round-trip worked out and then 2xx vs. 4xx is application logic.

But just eyeballing it, if the S3 library they're using works that way, there's a bug where if the upstream server behaves weirdly, Pleroma won't have a clue that this happened because it just assumes the server didn't return anything weird: https://git.freespeechextremist.com/gitweb/?p=fse;a=blob;f=lib/pleroma/uploaders/s3.ex;h=6dbef90856c2fba0f9f5bddc52d56743cef7c81d;hb=HEAD#l40 . A little lower, delete_file() checks status_code so it looks like ExAws.request/1 returns an object that has a status code in it, so it *looks* like the put_file code assumes it has succeeded in cases where it hasn't. But it's hard to tell, because https://hexdocs.pm/ex_aws_s3/ExAws.S3.html#put_object/4 doesn't seem to say.

In a lot of cases, Elixir seems like it's fighting Erlang; it's forcing some infelicities in control flow that end up erasing the niceness you'd get from pattern-matching.

Public

Notices where this attachment appears