There's an admin test that is failing in CI that isn't failing locally, so I'm going to put some debugging in in the next commits to try to figure out what's happening.

FYI, it is failing for me locally too 👀 Not that it helps much ... but I can possibly investigate a bit myself and see if I find anything.

If it helps:

/Users/sam/work/personal/flask-admin/flask_admin/contrib/fileadmin/azure.py(220)read_file()
-> blob = self._container_client.get_blob_client(path).download_blob()
(Pdb) ll
215         def read_file(self, path):
216             path = self._ensure_blob_path(path)
217             if path is None:
218                 raise ValueError("No path provided")
219             breakpoint()
220  ->         blob = self._container_client.get_blob_client(path).download_blob()
221             return blob.readall()
(Pdb) pp path
'dummy.txt'
(Pdb) n
azure.core.exceptions.DeserializationError: Unable to deserialize response data. Data: undefined, bytearray
> /Users/sam/work/personal/flask-admin/flask_admin/contrib/fileadmin/azure.py(220)read_file()
-> blob = self._container_client.get_blob_client(path).download_blob()

Thanks! Might be a statefulness thing, I'll start a fresh env.

...Wouldn't it be better to include actual information in that error variable? I.e. make it an optional string (containing the error message if an error occurred).

The check would work the same, and the error could be logged properly before redirect (...as it probably should be, anyway.)

@samuelhwilliams It was an error due to the tests using an older Azure storage emulator, I've updated them to the official Microsoft hosted emulator now, and they're passing fine.
@LeXofLeviafan I agree that it would be nice if the errors were easier to debug. They should probably be logged as either warning or error, depending on whether they're likely user errors or server errors. That would be better in a different PR though, I think. I'm trying to only affect the Azure module for this one.

Hm, it appears I still don't have an approach for handling unimportable Azure modules that makes mypy happy. Let me know if you have any thoughts about the best practice for importing extra modules in tests (and skipping tests if they don't exist). I'll take another look Monday otherwise.

I don't think we need to support tests running without azure installed - I'd probably be fine with you removing the try/except around that test import.

Okay, I've made it so that the tests assume you've got azure-blob-storage installed. I've also made the tests devcontainer bring in Postgres and Mongo too, so I was able to get all the tests passing in my dev container environment, without additional setup.

I can still reproduce an error on file renaming that looks like this

From a bit of playing around, it seems limited to large files (4MB+ or so) rather than JPG or a specific filetype. Can you reproduce with that?

I tried a larger file, no luck, but can you attach your large file and also tell me what you tried renaming it to? In theory, I should be able to replicate, given we're in a containerized environment. If I still fail, then I'll DM next week on Discord and see if we can hop on a screen share or some thing.

Following up on bug bash issues:

• Timestamps of directories: that was an existing issue, where directories always passed down a last modified of 0, for both Azure and S3. However, I went ahead and changed the logic for Azure to grab the timestamp, since that looks nicer.
• UTC timezones: that's expected for flask-admin, samuel has an example checked in that shows how to add user-specific timezone rendering for those who want it
• Possible memory leak with send_file: According to my research, there shouldn't be a leak.

I am still working through an issue with "rename" when connecting to a prod account using the connection string (versus using OAuth token-based connection).

I tried a larger file, no luck, but can you attach your large file and also tell me what you tried renaming it to? In theory, I should be able to replicate, given we're in a containerized environment. If I still fail, then I'll DM next week on Discord and see if we can hop on a screen share or some thing.

Unfortunately all of the files I've ended up reproducing it with are personal ones that I'd rather not share (eg a passport scan) 😂 I'm willing to accept that this might be something about my setup...

@samuelhwilliams I worked a bunch on this today, with help from an Azure Blob SDK engineer, and ended up changing the rename method so that it uses an asynchronous copy behind the scenes (versus synchronous).

Now the code works for me for:

• Local Azurite
• Prod Azure account with keyless auth
• Prod Azure account with connection string

I tested with files of up to a size of 5 GB on my prod Azure account, and was able to rename them all.
I don't know if this would resolve the issue you were seeing with Azurite, however, since I was never able to replicate that. It's possible.

I do not currently have any other planned changes, so I've marked this as ready for review again.

…There seems to have been no activity here for a few weeks by now. Was the work on this pull-request paused? 🤔

Sorry, just had some busy weeks! I will hopefully have time this week, if not, certainly next week.

Really appreciate your hard work and persistence on this @pamelafox - thank you 🙇

@samuelhwilliams I'm pushing a fix for the double-directory issue. That was introduced when I tried to remedy the issue of the Date field displaying a timestamp of 0:

However, from what I can see in the S3 code, it might have the same issue, and I think this has always been an issue for Azure. Removing that 1970 date would be a larger change involving the BaseFileAdmin and possibly the templates, depending on how sorting works.

For the record, Azure shows blank dates for directories, since directories aren't real entities:

I assume that I should just leave that be, for now? Let me know what you think.

I think it's fine to leave the timestamp issue for directories for now, agreed. That can be addressed separately 👍

Okay, then the only pending question is if we can get clarity on when/whether the async path for copying gets used. I've sent an inquiry to the Blob storage team, but don't know if I'll definitely get a response.

I've filed the date-for-directories issue here:
#2598