Troubleshooting

This page collects the issues we see most often and how to resolve them. For deeper diagnostics, every AI call is recorded in the API log (AI Assistant → API logs) with the full request, response, tokens, duration and error.

Confirm the plugin is activated under Extensions → My extensions.
Clear the admin cache: bin/console cache:clear.
Hard-reload the admin (Ctrl+Shift+R) so the browser fetches the new bundle.
If you self-build administration, rerun bin/build-administration.sh.
Check that your user role has access to the new ACL keys.

”Invalid API key” when testing a connection

Re-copy the key from the OpenAI dashboard. Most failures are silent whitespace at the end.
If you proxy OpenAI through a gateway, double-check the base URL and that your gateway forwards the Authorization header.

Jobs stuck in “running”

Check that bin/console messenger:consume async is actually running and not in a crash loop.
If a worker died mid-job, the plugin re-queues such jobs automatically every few minutes. Wait one cycle and recheck.
If a job keeps recovering but never completes, open the API log filtered by that job’s ID — a real error is being retried.

Jobs in “suspended” status

Suspended jobs are not stuck — they were paused because the provider returned a recoverable error (most commonly: quota exceeded, payment required, rate limit). The job remembers the next un-processed item, so you don’t lose progress.

Open the API log entry on the job to see the exact provider message.
Top up your AI account, raise the quota, or switch the job to a different AI connection.
Click Resume on the job. The worker picks up from where it stopped.

Inline edits or jobs produce empty output

Open the API log entry for the affected call. The full response body is there.
Common cause: the prompt asked for a JSON structure but the model returned prose. Edit the prompt’s user-prompt to remind the model of the schema (and run a test on product before saving).
Another common cause: the source field (description, name) is empty. The model has nothing to work with.

”URL fetch failed” in `describe_from_url`

The URL must be reachable from the Shopware host’s outbound network.
The plugin only extracts content if a matching fetch domain config exists for the URL’s host. To create one:
1. Run the inline action Suggest fetch domain config against the URL — the model proposes CSS selectors.
2. Save the proposal in AI Assistant → Fetch domain config.
3. Re-run the original action.

Cache shows stale prompt content

Resolved prompt templates are cached per worker process. After editing a prompt:

Wait for the cache TTL, or
Restart workers: bin/console messenger:stop-workers and let supervisor relaunch them, or
Hit Test on product — the test path bypasses the cache for that template.

Suggestion can’t be applied / “version conflict”

The product was edited (or had a new version created) between the AI call and the apply. Re-open the product, refresh, and apply again.

API log growth / disk usage

Every AI call is logged with its full request and response, so the log grows quickly on busy stores. The plugin automatically prunes old entries once a day to keep it bounded. If you see runaway growth, check that Shopware’s scheduled-task runner is enabled — without it, neither the automatic log cleanup nor the stuck-job recovery runs.

Where to look first

API logs — every call with its full payload and result. Filter by date, type or connection.
Job detail page — for batch problems, the per-item status tells you which step failed.
Cost chart — unexpected cost spikes usually point to an unintended feature enablement.

If you still can’t find the cause, the API log row for the failing call is the artefact to share with support.