[frontend/task statement] RST directive not displaying the expected image

[ClemCordier]

Describe the bug

When inserting an image in the task statement (using RST directive, e.g. .. image:: task_id/img.png), deleting the image file locally and replacing it by another one with the same name, the RST directive is still displaying the old image instead, as if it were cached.

INGInious installation details

• Version: v.0.8.5

To Reproduce

Steps to reproduce the behavior:

1. Insert an image inside the public folder of a task.
2. Use the .. image:: directive to display the image in the task statement.
3. Delete the image and replace it by another one with the same name.
4. Refresh the page - the old, deleted image is still showing instead of the newly inserted one.

Expected behavior

The current image stored inside the public folder to be displayed, not the old one that has been deleted locally.

Desktop (please complete the following information):

• OS: Windows
• Browser: Vivaldi

[Drumor]

I Just tested both on local and production server and have not experiment such issue. It's probably related to your browser configuration.

[anthonygego]

How do you change the file ? Via the web studio, the webdav, or the filesystem ? Do you perform this operation on your local setup or one of UCLouvain instance ?

It's possible that the webdav server does not keep track of the file modification date and thus flask think it's still the same file.

In our production instances static files are served by nginx so we could exclude werkzeug send_from_directory method in that case.

[ClemCordier]

How do you change the file ? Via the web studio, the webdav, or the filesystem ? Do you perform this operation on your local setup or one of UCLouvain instance ?

It's possible that the webdav server does not keep track of the file modification date and thus flask think it's still the same file.

In our production instances static files are served by nginx so we could exclude werkzeug send_from_directory method in that case.

Not sure what exactly are the 3 options you mentioned, but I did the file switch using the webdav file system (through the Windows file explorer) when I encountered the issue.

I just tried it with a test task and another simpler, smaller image. First through the INGInious frontend interface (drag & droping the file and modifying the path to public/ ) as well as the webdav filesystem, but neither method reproduced the error.

But I did manage to reproduce it on the same task with the same images (still using webdav filesystem, Windows file explorer).

I thought it could be related to the file size (4kB versus 52kB/55kB) so I came back to the test task, this time using the images that originally induced the error but I couldn't reproduce it with the same images on the test task.

Here are a few screenshots to illustrate the bug:

1. The directive included in the task statement:

2. The (wrong) image displayed to the student:

3. The actual expected_result.png image on the filesystem:

Hope it helps.

[anthonygego]

So If I understand well, the behaviour does not change (actual update or not) according to the method, but rather to the files themselves, or at least in some configuration not related to webdav ?

It's possible Windows Explorer does not show upload errors and keep the file in cache until it can retry and upload the file successfully. It would be worth reproducing the bug and note at what time it happend so that we can see in the logs if some error happened. Another way to check this is to disable browser cache and look at the file, or make another webdav mount at another location and check what the file look like.