[Bug]: Nextcloud Talk model request is canceled after ~5sec

[rhinterndorfer]

Affected component

channel

Severity

S3 - minor issue

Current behavior

When using a slow local LLM (e.g., LocalAI) that does not respond within ~5 seconds, the model request is canceled.
Inspecting the code for the handle_nextcloud_talk_webhook function in crates/zeroclaw-gateway/src/lib.rs shows that it makes a synchronous call to the LLM implementation.

Expected behavior

The webhook should return immediately, and the message should be processed asynchronously in the background.

Steps to reproduce

1. Run a slow LLM
2. Send a message via Nextcloud Talk
3. LLM logs: context canceled
4. ZeroClaw logs: no record of the cancellation

Impact

ZeroClaw aborts any Nextcloud Talk interaction that takes longer than approximately 5 seconds.

Logs / stack traces

ZeroClaw version

zeroclaw 0.7.3 / commit 0cd9d3b

Rust version

rustc 1.95.0 (59807616e 2026-04-14)

Operating system

Debian GNU/Linux 13 (trixie)

Regression?

No, first-time setup

Pre-flight checks

• I reproduced this on the latest master branch or latest release.
• I redacted secrets, tokens, and personal data from all submitted content.

[rhinterndorfer]

Solution proposal:

crates/zeroclaw-gateway/src/lib.rs line 2117 - 2150

        // Process the message asynchronously (non-blocking for the webhook response)
        let nextcloud_talk = nextcloud_talk.clone();
        let state = state.clone();
        let msg = msg.clone();
        
        tokio::spawn(async move {
            tracing::info!("Async processing Nextcloud Talk message for session={}", session_id);

            match Box::pin(run_gateway_chat_with_tools(
                &state,
                &msg.content,
                Some(&session_id),
            ))
            .await
            {
                Ok(response) => {
                    if let Err(e) = nextcloud_talk
                        .send(&SendMessage::new(response, &msg.reply_target))
                        .await
                    {
                        tracing::error!("Failed to send Nextcloud Talk reply: {e}");
                    }
                }
                Err(e) => {
                    tracing::error!("LLM error for Nextcloud Talk message: {e:#}");
                    let _ = nextcloud_talk
                        .send(&SendMessage::new(
                            "Sorry, I couldn't process your message right now.",
                            &msg.reply_target,
                        ))
                        .await;
                }
            }
        });

[Audacity88]

Triage Summary

Type: Bug
Priority: Medium
Area: channel, channel: nextcloud_talk, gateway
Risk: High

Summary: This looks valid. handle_nextcloud_talk_webhook currently awaits run_gateway_chat_with_tools before returning the webhook 200 OK, so a slow local model can keep the Nextcloud request open long enough for the client side to cancel it. The Gmail webhook already uses the non-blocking shape here, but the Nextcloud Talk fix should preserve signature verification, autosave/session behavior, reply delivery, and error reporting rather than only wrapping the existing call in tokio::spawn.

Duplicates/Related: No duplicate found from the exact context canceled / handle_nextcloud_talk_webhook searches. Related: #6157 appears to cover the follow-on Nextcloud Talk reply API failure once async processing is attempted.

Actionability: Ready for work. A good fix should add a regression test or focused harness proving the webhook acknowledges promptly while the background task continues processing and attempts the room reply.

Repro quality: Good. The report includes version/commit, environment, steps, observed LocalAI symptom, expected behavior, and the likely code path; local source inspection matches the blocking-webhook claim.