Alright I was able to get the error to go away and reproduce it.
TL;DR
- Going back to a previously working S3 setup and deleting and installing the DiscoTOC component results in an error free installation of the component.
- Disabling S3 by commenting out all the S3 directives in app.yml results in the error resurfacing when the component is installed, and I presume on update the error will come back as well.
- Setting
DISCOURSE_USE_S3: falsedoes not stop Discourse from using S3 paths, this feels like a bug or this setting doesn’t do what I think it does.
Detailed Overview
Initially what I did was revive my minio setup, uncommented the config options in my app.yml, rebuilt the app, and made sure to run the s3:upload_assets task. Once the site was back up I navigated to the components section. The already installed DiscoTOC component still showed the error, however, when I deleted it and re-installed it the error did not resurface. During the DiscoTOC component installation sprite.svg was requested from my S3 server.
As part of trying to reproduce the problem I ran into an interesting issue. It seems when l leave all the S3 directives in my app.yml active, i.e. not commented out, but set ``DISCOURSE_USE_S3: false``` the site frontend will not load if minio is not running.
Perhaps DISCOURSE_USE_S3: False is not meant to disable all S3 access, I assume it does based on the name but clearly it doesn’t. As soon as I restart the minio service and refresh the frontend everything works fine. I also am able to uninstall and install the DiscoTOC component without reproducing the error in this state. This seems like at least potentially one bug.
Here is the third state that lead me to the reproducible error.
In order to get my site to work without minio running again I commented out all of the entries that had anything to do with S3 in the config. Then I rebuilt the app and now with minio not running the frontend loads without a problem. However, if I uninstall and re-install the DiscoTOC component the error shows up again. I also tried just starting up minio in this state but the error showed up again on re-install. Most likely due to the fact that there were no S3 directives anywhere set in app.yml and so even if it was trying to reach out to S3 behind the scenes it would do it using default values rather than a working set up. It does, however, seem that some images are still trying to be served from S3 even after a posts:rebake. (e.g. 1531a70abda0d81d1a4039b6f3fa38bea79ef0de_2_180x180.png/xl.meta)