Context chat problems

ℹ️ Support
, , , , ,
1
Support intro

Sorry to hear you’re facing problems. :slightly_frowning_face:

The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.

If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.

Getting help

In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.

Before clicking submit: Please check if your query is already addressed via the following resources:

(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can. :heart:

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 33.0.3 AIO 13.0.4
  • Operating system and version (e.g., Ubuntu 24.04):
    • Truenas 25.10.3.1
  • Web server and version (e.g, Apache 2.4.25):
    • replace me
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • replace me
  • PHP version (e.g, 8.3):
    • replace me
  • Is this the first time you’ve seen this error? (Yes / No):
    • replace me
  • When did this problem seem to first start?
    • replace me
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • AIO
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • Cloudflare only for externa access.

Summary of the issue you are facing:

Environment: Nextcloud AIO on TrueNAS SCALE, Context Chat + context_chat_backend 5.3.0.
Background jobs are set to Cron and are running via:
docker exec -u www-data nextcloud-aio-nextcloud php -f /var/www/html/cron.php every 2 minutes.

Context Chat shows:

Total eligible files: 10407

Files in indexing queue: 3702 (3700 new)

Files successfully sent to backend: 6063

Indexed documents: files__default => 9538, mail__mail => 8355

mail__mail keeps increasing, but files__default barely moves.

occ background-job:list shows:

OCA\ContextChat\BackgroundJobs\IndexerJob with recent last_run

OCA\ContextChat\BackgroundJobs\FileSystemListenerJob and ActionJob with recent last_run

OCA\ContextChat\BackgroundJobs\SubmitContentJob with last_run = 1970-01-01T00:00:00+00:00

When I force the job with:
php occ background-job:execute 86753023916453888
it prints “Job executed!”, but running occ context_chat:stats afterwards shows no change in “Files successfully sent to backend” or files__default.

At the same time, the Mail app has:

“Make mails available to Context Chat” disabled in the user settings,

but mail__mail continues to be indexed and there are active OCA\Mail\BackgroundJob\ContextChat… jobs with recent last_run.

This looks like:

Context Chat’s SubmitContentJob for files not processing the file queue at all, and

the Mail → Context Chat integration not respecting the “Make mails available to Context Chat” toggle.

Configuration

Nextcloud

The output of occ config:list system or similar is best, but, if not possible, the contents of your config.php file from /path/to/nextcloud is fine (make sure to remove any identifiable information!):

{    "system": {        "one-click-instance": true,        "one-click-instance.user-limit": 100,        "memcache.local": "\\OC\\Memcache\\APCu",        "apps_paths": [            {                "path": "\/var\/www\/html\/apps",                "url": "\/apps",                "writable": false            },            {                "path": "\/var\/www\/html\/custom_apps",                "url": "\/custom_apps",                "writable": true            }        ],        "check_data_directory_permissions": false,        "memcache.distributed": "\\OC\\Memcache\\Redis",        "memcache.locking": "\\OC\\Memcache\\Redis",        "redis": {            "host": "***REMOVED SENSITIVE VALUE***",            "password": "***REMOVED SENSITIVE VALUE***",            "port": 6379,            "timeout": 3,            "read_timeout": 10        },        "overwritehost": "nextcloud.enghult.se",        "overwriteprotocol": "https",        "passwordsalt": "***REMOVED SENSITIVE VALUE***",        "secret": "***REMOVED SENSITIVE VALUE***",        "trusted_domains": [            "localhost",            "nextcloud.enghult.se",            "127.0.0.1",            "172.16.1.6",            "192.168.1.37"        ],        "datadirectory": "***REMOVED SENSITIVE VALUE***",        "dbtype": "pgsql",        "version": "33.0.3.2",        "overwrite.cli.url": "https:\/\/nextcloud.enghult.se\/",        "dbname": "***REMOVED SENSITIVE VALUE***",        "dbhost": "***REMOVED SENSITIVE VALUE***",        "dbport": "",        "dbtableprefix": "oc_",        "dbuser": "***REMOVED SENSITIVE VALUE***",        "dbpassword": "***REMOVED SENSITIVE VALUE***",        "installed": true,        "instanceid": "***REMOVED SENSITIVE VALUE***",        "maintenance": false,        "loglevel": 2,        "log_type": "file",        "logfile": "\/var\/www\/html\/data\/nextcloud.log",        "log_rotate_size": 10485760,        "log.condition": {            "apps": [                "admin_audit"            ]        },        "preview_max_x": 2048,        "preview_max_y": 2048,        "jpeg_quality": 60,        "enabledPreviewProviders": {            "0": "OC\\Preview\\Imaginary",            "1": "OC\\Preview\\ImaginaryPDF",            "2": "OC\\Preview\\ImaginaryPDF",            "3": "OC\\Preview\\ImaginaryPDF",            "4": "OC\\Preview\\ImaginaryPDF",            "5": "OC\\Preview\\Movie",            "6": "OC\\Preview\\ImaginaryPDF",            "7": "OC\\Preview\\ImaginaryPDF",            "8": "OC\\Preview\\ImaginaryPDF",            "9": "OC\\Preview\\HEIC",            "10": "OC\\Preview\\ImaginaryPDF",            "11": "OC\\Preview\\TIFF",            "12": "OC\\Preview\\ImaginaryPDF",            "13": "OC\\Preview\\ImaginaryPDF",            "14": "OC\\Preview\\Image",            "23": "OC\\Preview\\ImaginaryPDF"        },        "enable_previews": true,        "upgrade.disable-web": true,        "mail_smtpmode": "smtp",        "trashbin_retention_obligation": "auto, 30",        "versions_retention_obligation": "auto, 30",        "activity_expire_days": 30,        "simpleSignUpLink.shown": false,        "share_folder": "\/Shared",        "one-click-instance.link": "https:\/\/nextcloud.com\/all-in-one\/",        "upgrade.cli-upgrade-link": "https:\/\/github.com\/nextcloud\/all-in-one\/discussions\/2726",        "updatedirectory": "\/nc-updater",        "maintenance_window_start": 100,        "allow_local_remote_servers": true,        "davstorage.request_timeout": 3600,        "documentation_url.server_logs": "https:\/\/github.com\/nextcloud\/all-in-one\/discussions\/5425",        "htaccess.RewriteBase": "\/",        "dbpersistent": false,        "auth.bruteforce.protection.enabled": true,        "ratelimit.protection.enabled": true,        "files_external_allow_create_new_local": true,        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",        "preview_imaginary_url": "***REMOVED SENSITIVE VALUE***",        "preview_imaginary_key": "***REMOVED SENSITIVE VALUE***",        "memories.db.triggers.fcu": true,        "memories.exiftool": "\/var\/www\/html\/custom_apps\/memories\/bin-ext\/exiftool-amd64-musl",        "memories.vod.path": "\/var\/www\/html\/custom_apps\/memories\/bin-ext\/go-vod-amd64",        "memories.vod.ffmpeg": "\/usr\/bin\/ffmpeg",        "memories.vod.ffprobe": "\/usr\/bin\/ffprobe",        "default_phone_region": "SE",        "mail_sendmailmode": "smtp",        "mail_from_address": "***REMOVED SENSITIVE VALUE***",        "mail_domain": "***REMOVED SENSITIVE VALUE***",        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",        "mail_smtpport": "465",        "mail_smtpauth": 1,        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",        "memories.gis_type": 2,        "updater.release.channel": "stable",        "updatechecker": false,        "data-fingerprint": "3a7b7fb10445bdab7085cdaf526a7648",        "facerecognition.external_model_url": "nextcloud-aio-facerecognition:5000",        "facerecognition.external_model_api_key": "***REMOVED SENSITIVE VALUE***",        "enabledFaceRecognitionMimetype": [            "image\/jpeg",            "image\/png",            "image\/heic",            "image\/tiff",            "image\/webp"        ],        "memories.vod.disable": false,        "memories.vod.external": true,        "memories.vod.connect": "nextcloud-aio-memories:47788",        "serverid": 473,        "log_type_audit": "file",        "logfile_audit": "\/var\/www\/html\/data\/audit.log",        "app_install_overwrite": [            "occweb"        ],        "DOMAIN": "nextcloud.enghult.se",        "AIO_VERSION": "v13.0.4"    }}

Apps

The output of occ app:list (if possible).

Tips for increasing the likelihood of a response

  • Use the preformatted text formatting option in the editor for all log entries and configuration output.
  • If screenshots are useful, feel free to include them.
    • If possible, also include key error output in text form so it can be searched for.
  • Try to edit log output only minimally (if at all) so that it can be ran through analyzers / formatters by those trying to help you.
2

Hi,

I was fighting with deeper Context Chat / AppAPI / context_chat_backend problems yesterday on a related setup.

My setup is not exactly the same as yours, because I am on AIO 13.1.0 beta, but the affected components are very close:

Nextcloud 33.0.3
app_api 33.0.0
context_chat 5.3.1
context_chat_backend 5.3.0
context_agent 2.6.0
talk_bot_ai 3.2.0

So maybe my findings can still help to narrow this down.

I would be careful with the conclusion that OCA\ContextChat\BackgroundJobs\SubmitContentJob is necessarily the root cause here.

In my case the problem looked worse at first: the file indexing pipeline was basically stuck, Files successfully sent to backend was 0, the backend was only receiving /countIndexedDocuments, and /loadSources was not appearing at all.

I later found multiple issues:

- missing ContextChat file background jobs
- stale AppAPI ExApp cache after reinstalling the backend
- AppConfigTypeConflictException caused by context_chat/auto_indexing being stored with the wrong appconfig type

Your case looks related, but not identical, because your stats already show that files were successfully sent to the backend and that files__default already contains many indexed documents.

So the backend does not look completely disconnected from the file provider. It looks more like the file indexing pipeline is partially working, but either very slow, waiting for the next IndexerJob interval, or stuck on a specific IndexerJob / StorageCrawlJob / file / mount.

Before resetting the backend or unregistering the ExApp, I would first check whether the backend is still receiving file batches:

sudo docker logs --since 2h nc_app_context_chat_backend | egrep -i "loadSources|countIndexedDocuments|v1/embeddings|200 OK|500|503|error|exception|failed|timeout" | tail -200

A healthy file indexing run should show things like:

PUT /loadSources HTTP/1.1" 200 OK
POST /v1/embeddings HTTP/1.1" 200 OK
POST /countIndexedDocuments HTTP/1.1" 200 OK

I would also check whether IndexerJob or StorageCrawlJob is throwing errors in nextcloud.log, not only whether SubmitContentJob has last_run = 1970.

For example:

sudo docker exec -i --user www-data nextcloud-aio-nextcloud php <<'PHP'
<?php
$log = '/var/www/html/data/nextcloud.log';
$lines = @file($log, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);

$shown = 0;
$since = time() - 7200;

for ($i = count($lines) - 1; $i >= 0 && $shown < 20; $i--) {
    $row = json_decode($lines[$i], true);
    if (!is_array($row)) {
        continue;
    }

    $time = isset($row['time']) ? strtotime($row['time']) : 0;
    if ($time < $since) {
        continue;
    }

    $haystack = json_encode($row, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE);

    if (
        str_contains($haystack, 'OCA\\ContextChat\\BackgroundJobs\\IndexerJob')
        || str_contains($haystack, 'OCA\\ContextChat\\BackgroundJobs\\StorageCrawlJob')
        || str_contains($haystack, 'OCA\\ContextChat\\BackgroundJobs\\SubmitContentJob')
        || str_contains($haystack, 'AppConfigTypeConflictException')
        || str_contains($haystack, 'context_chat')
        || str_contains($haystack, 'context_chat_backend')
    ) {
        echo "\n=== RECENT MATCH ===\n";
        echo "time: " . ($row['time'] ?? '') . "\n";
        echo "app: " . ($row['app'] ?? '') . "\n";
        echo "message: " . ($row['message'] ?? '') . "\n";

        if (isset($row['exception']) && is_array($row['exception'])) {
            echo "exception class: " . ($row['exception']['Exception'] ?? $row['exception']['class'] ?? '') . "\n";
            echo "exception message: " . ($row['exception']['Message'] ?? $row['exception']['message'] ?? '') . "\n";
        }

        $shown++;
    }
}

echo "\nRecent matches shown: $shown\n";
PHP

One more thing I would verify is the raw appconfig type for context_chat/auto_indexing.

In my case this key had been stored as a boolean type, but the Context Chat IndexerJob reads it as a string. That caused:

OCP\Exceptions\AppConfigTypeConflictException
conflict with value type from database

Check it with:

sudo docker exec -i --user www-data nextcloud-aio-nextcloud php <<'PHP'
<?php
require_once "/var/www/html/lib/base.php";

$db = \OC::$server->get(\OCP\IDBConnection::class);

$qb = $db->getQueryBuilder();
$qb->select('appid', 'configkey', 'configvalue', 'type', 'lazy')
   ->from('appconfig')
   ->where($qb->expr()->eq('appid', $qb->createNamedParameter('context_chat')))
   ->andWhere($qb->expr()->eq('configkey', $qb->createNamedParameter('auto_indexing')));

$row = $qb->executeQuery()->fetch();

foreach ($row ?: [] as $key => $value) {
    echo $key . " = " . var_export($value, true) . "\n";
}
PHP

If you see recent IndexerJob errors together with AppConfigTypeConflictException, then the problem may be similar.

But if there are no errors and the backend log still shows /loadSources and /v1/embeddings, I would not reset the backend yet. In that case I would compare context_chat:stats over time and check whether these numbers are still moving:

Files in indexing queue
Files successfully sent to backend
Indexed documents: files__default

The important distinction is that your backend already seems to have accepted file documents before, so I would first investigate IndexerJob, StorageCrawlJob, backend logs, and possible per-file/per-mount errors before doing anything destructive like unregistering context_chat_backend with --rm-data.

3

Environment

  • Platform: Nextcloud AIO running on TrueNAS.

  • AI stack: Context Chat enabled, Assistant/OpenAI integration present.

  • Mail app: mail 5.8.0, currently disabled.

Context Chat status

Current occ context_chat:stats (values approximate, but stable):

  • Total eligible files: 10407

  • Files in indexing queue: 3700

  • New files in indexing queue (without updates): 3700

  • Files successfully sent to backend: 6048

  • Indexed documents:

    • files__default: 9538

    • mail__mail: 8397

  • Actions in queue: 1

  • File system events in queue: 0

So, most files and many mails are indexed and usable in Context Chat, but a large number of files remain reported as “in queue” and do not seem to progress.

Background jobs

Current occ background-job:list (relevant entries):

  • Context Chat:

    • OCA\ContextChat\BackgroundJobs\SubmitContentJob – still shows last_run = 1970-01-01T00:00:00+00:00.

    • OCA\ContextChat\BackgroundJobs\FileSystemListenerJob – normal, recent last_run.

    • OCA\ContextChat\BackgroundJobs\ActionJob – normal, recent last_run.

    • OCA\ContextChat\BackgroundJobs\RotateLogsJob – normal, recent last_run.

  • Mail:

    • After disabling the Mail app via php occ app:disable mail and running php occ maintenance:repair, there are no OCA\Mail\BackgroundJob\ContextChat\* jobs left in the background job list.

    • Other Mail jobs (SyncJob, etc.) were present before disabling Mail, but are now gone as expected.

Cron appears to run correctly in general, and many other jobs (DAV, Files, Assistant, OpenAi, Memories, etc.) show regular, recent last_run timestamps.

Mail indexing behaviour

  • Before disabling Mail, mail__mail was increasing and there were OCA\Mail\BackgroundJob\ContextChat\SubmitContentJob and ScheduleJob entries.

  • Even with “Make mails available to Context Chat” turned off in the Mail settings for the user, mail documents continued being indexed into Context Chat.

  • After disabling Mail (app:disable mail) and running maintenance:repair:

    • All Mail‑ContextChat jobs disappeared from the background job list.

    • mail__mail in context_chat:stats stopped increasing and now stays constant at 8397.

  • This confirms that mail indexing is effectively stopped only when the Mail app itself is disabled, not when the Mail → Context Chat toggle is off.

File indexing behaviour

  • files__default is at 9538 and Files successfully sent to backend at 6048, so file indexing clearly worked to a large extent.

  • However, Files in indexing queue remains at 3700 and has not decreased noticeably over time.

  • Since most files are already indexed and Context Chat works for them, this looks like an inconsistent or stuck indexing state: the stats show a large queue, but it does not progress even though cron and other jobs run normally.

Admin actions already taken

I have already:

  1. Verified cron is running (many jobs across core and apps have fresh last_run timestamps).

  2. Used php occ background-job:execute on Context Chat jobs (SubmitContentJob, ActionJob, FileSystemListenerJob, RotateLogsJob) for debugging.

  3. Run php occ maintenance:repair multiple times (no critical errors, only normal messages).

  4. Disabled and re-enabled Context Chat (php occ app:disable context_chat / app:enable context_chat) and re-ran maintenance:repair, which re‑registered Context Chat background jobs.

  5. Disabled the Mail app (php occ app:disable mail) and re-ran maintenance:repair to stop Mail → Context Chat integration. This successfully removed Mail‑ContextChat background jobs and froze mail__mail at a constant value.

Current state / question

  • Context Chat is usable and helpful: most files and previously indexed mails are searchable and appear in Context Chat.

  • Mail indexing is intentionally stopped by disabling the Mail app.

  • File indexing shows a persistent queue of 3700 files, with files__default and “Files successfully sent to backend” barely changing over time, despite cron running normally.

I would like to know:

  • If this “stuck queue” state (large number of files in indexing queue while most files are already indexed) is a known issue for the current Context Chat + backend + AppAPI versions.

  • Whether there is a recommended way (occ commands, re‑scan, reset, etc.) to safely clear or re‑process the remaining queue without breaking the existing index.

  • And whether the Mail → Context Chat toggle (inside the Mail app) is expected to be sufficient to stop mail indexing, or if disabling the entire Mail app is currently the only reliable workaround.

4

That makes sense, and your latest summary makes the situation much clearer.

Just to clarify my position: I am not a developer, only a Nextcloud AIO user who recently had to debug a deeper Context Chat / AppAPI / backend problem. So I cannot confirm the root cause, but I can compare it with what I saw from a user/admin perspective.

From my side, I would treat this as two separate issues rather than one single Context Chat problem:

  1. File indexing queue remains stuck even though most files are already indexed and usable.
  2. Mail → Context Chat indexing does not seem to fully stop when only the Mail setting is disabled.

The second point looks especially suspicious to me. If the Mail setting says that mails should not be made available to Context Chat, I would expect the Mail Context Chat jobs to respect that. Your test suggests that disabling the whole Mail app is currently the only reliable way to stop mail indexing.

For the file queue, I would also avoid destructive resets for now, because your existing index is already usable. If the queue stays at the same value for many hours or days, this looks more like an inconsistent/stuck indexing state than a completely broken backend.

Since you already confirmed that cron is running, background jobs are generally working, Mail Context Chat jobs disappear after disabling Mail, and the remaining file queue does not progress, I think this is probably worth reporting directly to the app maintainers.

Your latest summary already looks like a good basis for a GitHub issue. I would include:

  • Nextcloud / AIO version
  • context_chat and context_chat_backend versions
  • Mail app version
  • context_chat:stats before and after disabling Mail
  • relevant background-job:list entries
  • confirmation that cron works
  • confirmation that Mail indexing only stops after disabling the Mail app
  • confirmation that the file queue remains stuck while the existing index is usable

I cannot confirm the root cause, but based on your tests this looks like behaviour that should probably be checked by the Context Chat / Mail app maintainers rather than solved by random backend resets.

5

Hi,

I am testing Nextcloud Assistant Context Chat on Nextcloud AIO and I seem to be stuck in an inconsistent indexing state even after recreating the Context Chat Backend from scratch.

Environment

  • Nextcloud: AIO (Hub 32, latest as of June 2026)

  • Context Chat app: 5.3.x

  • Context Chat Backend: 5.3.0

  • AppAPI: 32.0.0 (AIO default)

  • Assistant / Context Agent: latest from AIO stack

  • External embedding backend: Ollama, reachable at http://192.168.1.37:30068/v1

    • Embedding model configured as: nomic-embed-text:latest

  • Only Files is enabled as a content provider in Context Agent (Mail is disabled)

What I did

  1. Originally I had a huge mail__mail queue and inconsistent indexing (queue growing, almost no progress).

  2. I removed the Context Chat Backend Ex‑App including its settings.

  3. I deployed a fresh Context Chat Backend with:

    • External OpenAI-compatible endpoint: http://192.168.1.37:30068/v1

    • External embedding model name: nomic-embed-text:latest

    • All other advanced options left empty (no custom Postgres URI, no auth).

  4. I confirmed in the admin UI that:

    • “The Context Chat Backend app is installed and responsive.”

    • Only files__default is listed as content provider; no mail__mail.

  5. I ran the indexer manually inside the Nextcloud container:

    bash

    php cron.php "OCA\\ContextChat\\BackgroundJobs\\IndexerJob"
    php occ context_chat:stats

Current stats

After several runs of IndexerJob, the stats are stable at:

text

ContextChat statistics:
The indexing is not complete yet.
Total eligible files: 10398
Files in indexing queue: 3705
New files in indexing queue (without updates): 3700
Queued documents (without files): array (
)
Files successfully sent to backend: 6127
Indexed documents: array (
)
Actions in queue: 0
File system events in queue: 0

On the Context Chat admin page I see:

  • The initial indexing is still running.

  • The Context Chat Backend app is installed and responsive.

  • Content provider:

    • files__default → 3705 (3700 new files) and (6127 sent)

  • Queued documents (without files) is empty (no mail__mail anymore).

Backend log (ccb.log)

The new backend log (after the clean reinstall) shows no embedding activity at all – only startup and regular “currently indexing 0 documents” messages.

Representative snippet:

text

timestamp 2026-06-03T15:21:34.298070, level INFO, logger uvicorn.error,
message Started server process 98
timestamp 2026-06-03T15:21:34.378885, level INFO, logger ccb.controller,
message App enable state at startup False
timestamp 2026-06-03T15:21:51.812288, level INFO, logger ccb.controller,
message App enabled
timestamp 2026-06-03T15:21:54.380995, level INFO, logger ccb.controller,
message Currently indexing 0 documents
timestamp 2026-06-03T15:22:04.381593, level INFO, logger ccb.controller,
message Currently indexing 0 documents
...
(repeated "Currently indexing 0 documents" every 10 seconds)
...
timestamp 2026-06-03T15:23:19.256645, level DEBUG, logger ccb.vectordb,
message counting documents by provider
timestamp 2026-06-03T15:23:19.279313, level INFO, logger uvicorn.access,
message POST countIndexedDocuments HTTP/1.1 200
...
(and so on, but **no** "Embedding sources", **no** "loadSources",
**no** errors about the embedding backend)

So:

  • The backend container is healthy and responds to heartbeat and countIndexedDocuments.

  • But it never receives any loadSources calls and never logs “Embedding sources” or similar.

  • From the PHP side, there are 3705 files in the queue, but Indexed documents is completely empty and doesn’t move.

What I expected

After deleting and recreating the Context Chat Backend and running IndexerJob, I expected:

  • Files in indexing queue to start decreasing from 3705

  • Indexed documents: 'files__default' => N to appear and grow

  • Backend logs to show at least some loadSources / embedding activity

Instead, the queue remains stuck at 3705, and the backend just reports “Currently indexing 0 documents”.

Question

Is this a known issue with Context Chat 5.3.x + Backend 5.3.0 on AIO, where the PHP app stops sending jobs to a freshly recreated backend?

Anything I can do to “re-bind” the Context Chat app to the new backend instance or to flush/repair the internal queue so that files start flowing again?

Happy to provide full logs or run additional occ commands if needed.