[Bug]: Map assets are Red X's when map is imported by a connected client

[kwvanderlinde]

Describe the Bug

In some circumstances, images on imported maps will show as Red X's on the server despite the client showing them properly. The conditions are:

1. The map is imported from a remote client.
2. The image is in the client's asset cache.
3. The image is not in the server's asset cache.

To Reproduce

1. On the client machine, create a map with a couple of tokens on it. Double check that the token images are in the client's asset cache. Export the map, then restart MapTool.
2. On the server machine, clear the asset cache, then start MapTool. Start a server. Double check that the token images from (1) are not in the server's asset cache.
3. On the client machine, connect to the server as a GM. import the map from (1). Verify that the tokens appear as expected.
4. On the server machine, look at the newly imported map. The tokens will appear as Red X's.

Expected Behaviour

Imported maps should have their assets sent to the server.

Screenshots

No response

MapTool Info

MapTool 1.14.3

Desktop

Linux Mint 21.3

Additional Context

No response

[kwvanderlinde]

I have yet to test this thoroughly, but I believe this bug is not just about map assets, but applies to any assets that a client can import (tables, etc). Token drag-and-drop works, but that seems to be because there is additional logic to make sure those assets are pushed.

While testing the token drag-and-drop, I also encountered a rather annoying popup when dragging an RPTOK file. It only shows during development:

Please report this: (!isHostingServer() && !isPersonalServer()) == true

[cwisniew]

It's probably a little more complicated than just sending the assets to the server. Currently, if the zone gets to the server before the images (which it will for most, if not all, if you queue up assets and zone at the same time). If the GM or players select the new map before assets are transferred, they will still get a red X. I think restarting MT will be the only way to display this (I could be wrong, a map change might work).
So, we would need one of the following mechanisms:

1. Don't queue map until after assets have been transferred
2. Keep track of each red X for a missing asset, and when an asset is added to the server or client, tell any zone displaying a red X to reload that asset, and if it's the server, send the asset to the clients

Or both :)

Honestly, number 2 might offer a path to solving some of the other odd red X cases that pop up now and again

[kwvanderlinde]

Yes, definitely more complicated, but not badly so. We just need to recognize cases where an asset is in progress being uploaded to the server. If so, the server shouldn't consider the asset "broken" (red X) but instead should assign an AssetProducer as if the asset was already on the server. We just delay pushing the asset data until the server receives it. From the requesting client's perspective things are no different aside from a slightly longer delay if the server is still receiving the asset. I'll try put up a POC to show this idea off.

Bigger issue now that I've seen the code for this: I see there is a lot of client-side logic that blocks until an asset is available, e.g., for showing a <img src="asset://..."> in chat. If that asset has to come from the server that can hang the client for an indefinite time, which would be even worse if waiting on yet another client to provide it. And if anything goes wrong such that the asset stops transferring that can cause a client to permanently hang. So I think a good first step will be to reduce the amount of these blocking calls and introduce some robustness (timeouts or something), then tackle the bug itself.