Describe the Bug
With debug: true set in the config, docker logs still shows almost nothing about indexing. The detail is produced — it goes to persistent_storage/logs/ccb.log — but the stream a container deployment is actually read from stays nearly silent, because the stderr handler is pinned at WARNING:
# logger_config.yaml
handlers:
stderr:
class: logging.StreamHandler
level: WARNING
...
file_json:
class: logging.handlers.RotatingFileHandler
level: DEBUG
filename: logs/ccb.log
logger_config.k8s.yaml has the stderr handler at DEBUG, so the k8s deployment does not have this problem — only the manual-install and Docker paths do.
Why it matters
Everything that describes what indexing is doing is at INFO or DEBUG:
Using N parallel file parsing workers
Dispatching N file chunk(s)
Waiting for file chunk 1/8 future to complete
embed_sources finished for 4 source(s): 3 succeeded, 1 errored and the per-source error dict
No documents to index
None of it reaches docker logs. What does reach it is the ERROR from a failed queue fetch, so the visible log is a stream of tracebacks with no surrounding context.
The practical consequence is that a healthy-but-slow run and a genuinely stuck one look identical from outside the container. We spent a long time treating the silence as evidence that the indexing thread had died — it had not; it was working and simply not saying so where we were looking. The information that eventually resolved it was in ccb.log the whole time.
Suggested fix
Have debug: true also lower the stderr handler, so turning debug on makes the logs visible where they are read. PR follows.
Two smaller things noticed nearby
context_chat_backend/network_em.py:24 uses logging.getLogger('ccb.nextwork_em') — looks like a typo for network_em.
_setup_log_levels() in main.py lists the ccb.* loggers explicitly but omits ccb.task_fetcher and ccb.nextwork_em. It is harmless today, since they inherit DEBUG from the ccb parent configured in the YAML, but the list reads as if it were exhaustive.
Setup Details
Nextcloud version: 34.0.3
context_chat / context_chat_backend: 5.4.0 / 5.4.1
Deployment: manual-install deploy daemon, Docker, four backend instances
Describe the Bug
With
debug: trueset in the config,docker logsstill shows almost nothing about indexing. The detail is produced — it goes topersistent_storage/logs/ccb.log— but the stream a container deployment is actually read from stays nearly silent, because thestderrhandler is pinned atWARNING:logger_config.k8s.yamlhas the stderr handler atDEBUG, so the k8s deployment does not have this problem — only the manual-install and Docker paths do.Why it matters
Everything that describes what indexing is doing is at
INFOorDEBUG:Using N parallel file parsing workersDispatching N file chunk(s)Waiting for file chunk 1/8 future to completeembed_sources finished for 4 source(s): 3 succeeded, 1 erroredand the per-source error dictNo documents to indexNone of it reaches
docker logs. What does reach it is theERRORfrom a failed queue fetch, so the visible log is a stream of tracebacks with no surrounding context.The practical consequence is that a healthy-but-slow run and a genuinely stuck one look identical from outside the container. We spent a long time treating the silence as evidence that the indexing thread had died — it had not; it was working and simply not saying so where we were looking. The information that eventually resolved it was in
ccb.logthe whole time.Suggested fix
Have
debug: truealso lower the stderr handler, so turning debug on makes the logs visible where they are read. PR follows.Two smaller things noticed nearby
context_chat_backend/network_em.py:24useslogging.getLogger('ccb.nextwork_em')— looks like a typo fornetwork_em._setup_log_levels()inmain.pylists theccb.*loggers explicitly but omitsccb.task_fetcherandccb.nextwork_em. It is harmless today, since they inheritDEBUGfrom theccbparent configured in the YAML, but the list reads as if it were exhaustive.Setup Details
Nextcloud version: 34.0.3
context_chat / context_chat_backend: 5.4.0 / 5.4.1
Deployment: manual-install deploy daemon, Docker, four backend instances