lightbox: Download manager fails to download from {image_url}.

[jackrzhang]

This is a follow-up to #3123 (and I think the last step of #2618)!

After a user grants EXTERNAL_WRITE_STORAGE permission in order to download an image, this error is thrown (screenshot from an emulator running the debug build):

(@zulipbot add "area: android")
(@zulipbot claim)

[gnprice]

Quick note from our web searching just now:

https://developer.android.com/reference/android/app/DownloadManager.html#STATUS_FAILED

STATUS_FAILED
Value of COLUMN_STATUS when the download has failed (and will not be retried).
Constant Value: 16 (0x00000010)

Not a ton of information in that code, but that at least is very likely what the 16 is.

[jackrzhang]

This reproduces only on zulipchat.com, so I bet the issue is that the download isn't being authenticated properly (as documented in #2618).

[jackrzhang]

Posting the corresponding thread on czo here: https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/Android.20auth.20on.20zulipchat.2Ecom

[jackrzhang]

Relaying over information from the conversation in the thread above:

• This bug wasn't reproducing on the dev server, meaning that there's some difference between zulipchat.com and the dev server. Specifically, the Django server on zulipchat.com wasn't recognizing an image download request's Authorization header; the server was responding with 401 and logging unauth. On the dev server, the header was coming through fine, and the mobile client was successfully downloading the image.
• @timabbott did a bit of investigation into the nginx configuration and found that the API auth headers weren't being passed to any API routes that didn't start with /api (which include /user_uploads). Changes to the configuration were merged as zulip/zulip@ededdc5.
• After the nginx change, the server on zulipchat.com recognized the authentication / logged ([email protected] via ZulipMobile) and returned a status code of 302.

So, the authentication issue may have been fixed with zulip/zulip@ededdc5, and now there's one more issue with the redirect. I'll start debugging by just hardcoding the dev environment to always serve a redirect to a fixed image.

[gnprice]

We heard a fresh report of this today, from a user who'd just started using Zulip with their team. They posted a screenshot showing an error message of exactly the same form as in the description above:

So, a confirmation that this issue is still live and a reminder that it affects people using Zulip.

[gnprice]

This issue is now fixed! Thanks to @agrawal-d in #4089.

We also had a previous issue #2115 which in retrospect is pretty clearly the same issue. That one didn't have much detail or any useful labels on it, which is probably why we didn't notice it at the time we filed this one. I've now marked that one as a duplicate of this.