[bug]: UI doesn't show labels

[tdpires]

Is there an existing issue for this problem?

• [X] I have searched the existing issues

Operating system

Linux

GPU vendor

Nvidia (CUDA)

GPU model

A10G

GPU VRAM

24GB

Version number

3.7.0

Browser

Chrome latest

Python dependencies

No response

What happened

When trying to deploy with Docker, the UI comes up but all the labels are showing what seems to be non localized strings. Can't generate images with Invoke button. It was working before for version 3.6. Saw an issue where it stated deleting local store cache could fix but it did not. Replicated on another browser.

What you expected to happen

Expected a usable UI.

How to reproduce the problem

No response

Additional context

Screenshot:

Discord username

No response

[psychedelicious]

What happens when you click the invoke button? Any errors?

[tdpires]

I get a red queue error in the bottom right corner.

[psychedelicious]

Sorry, I should have been more clear. Do you see any errors in the JavaScript console and or terminal?

Please copy and paste the full terminal output with startup messages.

[tdpires]

That button actually doesn't do anything now:

[tdpires]

These are my console errors:

[tdpires]

Here is my build output in Docker, which is successful: docker output.txt But then i get this after the build in the cosole: [2024-02-19 02:01:15,736]::[InvokeAI]::WARNING --> Could not modify the config file at /invokeai/configs/models.yaml [2024-02-19 02:01:15,736]::[InvokeAI]::WARNING --> [Errno 13] Permission denied: '/invokeai/configs/new_config.tmp' [2024-02-19 02:01:15,737]::[InvokeAI]::WARNING --> Could not modify the config file at /invokeai/configs/models.yaml [2024-02-19 02:01:15,737]::[InvokeAI]::WARNING --> [Errno 13] Permission denied: '/invokeai/configs/new_config.tmp'

[tdpires]

Invokeai.yaml file:

InvokeAI: Web Server: host: 0.0.0.0 port: 9090 allow_origins: [''] allow_credentials: true allow_methods:

• '*' allow_headers:
• '*' Features: esrgan: true internet_available: true log_tokenization: false patchmatch: true Memory/Performance: always_use_cpu: false free_gpu_mem: false max_cache_size: 6.0 max_vram_cache_size: 5.0 precision: auto sequential_guidance: false xformers_enabled: true tiled_decode: false Paths: autoimport_dir: autoimport lora_dir: null embedding_dir: null controlnet_dir: null conf_path: configs/models.yaml models_dir: models legacy_conf_dir: configs/stable-diffusion db_dir: databases outdir: /data/outputs # set to /data/outputs if you have persistent storage use_memory_db: true Logging: log_handlers:
• console log_format: color log_level: warning

[psychedelicious]

Thanks. Just to confirm, are you using the process outlined in the docker/ dir in the repo root?

[tdpires]

Yes, I am. This used to work; however, after updating to 3.6, it stopped. I tried 3.7 when it came out but it has the same issue. More info: we ran this on a private huggingface space with persistent storage and an A10G (24GB VRAM) space and it would run very fast for us.

EDIT: I would like to add, this is a fresh install.

This is failed request example. Fetching an asset (en.json) that exists in the dist folder on the container.

[tdpires]

It looks like the url is swapped when building using fetchBaseQuery. Instead of putting the asset after the URL, it's putting it after the sign parameter: `https://yoursite.com/locale/en.json?sign=XXXXXXXXXXXXXX it's outputting https://yoursite.com/?__sign=XXXXXXXXXXXXXX/locale/en.json`

[tdpires]

I don't get a 404 when i swap the parameter and the asset it's trying to fetch. How do I fix this in the source?

[tdpires]

OK I think i figured it out. A private space requires a signed call to fetch and looks like the code is just inserting the the path to the end of the URL with the query instead of between the URL and the query.

[tdpires]

If there was a way to accommodate these types of URLs carrying extra params that would be great

[psychedelicious]

Good catch! I tried docker locally and didn't have this issue, and I didn't make the connection with the URL.

Ok, we can definitely support these URLs. There are a few places where we'll need to fix the URLs. I'll take care of it.

[hipsterusername]

Going to close this as I believe it's being tracked in a different issue/PR

[psychedelicious]

@hipsterusername which issue? This is the one afaik

[ijussit]

I updated Invoke to 3.7 today and had the same problem as in the picture above, in my case it was the browser.