Problem with HaRP registration for context_chat_backend

ℹ️ 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).

I had problems getting Nextcloud Assistant Context Chat up and running, and spent many hours in dialogue with Claude to find a solution. Here’s Claude’s brief summary, hope it can be helpful to others:

What was the real problem?

HaRP’s FRP tunnel registration never completed for context_chat_backend. HaRP (the AppAPI reverse proxy bundled with Nextcloud AIO) uses FRP (Fast Reverse Proxy) tunnels to route traffic to ExApp containers. For reasons that were never fully identified, this specific ExApp’s tunnel entry was never populated in HaRP’s internal routing table — even after repeated unregister/re-register cycles, daemon restarts, and full container redeployments. Every request to /context_chat_backend/* returned “Invalid request path, cannot find AppID.”

This had a cascade of consequences:

  • Nextcloud couldn’t reach the container to send PUT /enabled, so the embedding server stayed stuck in a 30-minute wait loop and never loaded the model

  • The model download trigger (also fired via HaRP) never ran, so the model file was missing entirely

  • All real indexing and query traffic failed with “response body is not valid JSON” (actually HaRP’s plain-text 404)

There were also two secondary issues hit along the way: a broken PostgreSQL data directory from an interrupted first-run initdb, and a mismatched APP_SECRET after re-registration.

What was the solution?

Bypass HaRP entirely using AppAPI’s manual_install daemon with host networking.

  1. Registered a manual_install deploy daemon pointing directly at the host IP

  2. Re-registered context_chat_backend against that daemon

  3. Manually ran the container with --network host so port 23000 is reachable directly at 192.168.1.179:23000

  4. Manually downloaded the embedding model (multilingual-e5-large-instruct-q6_k.gguf) into the persistent volume

  5. Nextcloud could then reach the container directly, the heartbeat succeeded, PUT /enabled fired automatically, the embedding server loaded the model, and indexing of your 25 documents started cleanly

The tradeoff is that AppAPI no longer manages the container’s lifecycle — upgrades require a manual pull/re-register/redeploy sequence rather than clicking “Update” in the Apps UI.