Hi Samuel.
Hatte ich am WE auch mal. Lag aber an meiner VPN-Konfiguration… und somit tatsächlich nicht erreichbarem Server.
Auf jeden Fall Container, nicht Proxy(?).
Denke aber, das kommt wenn der Server gar nicht erst erreichbar ist und die Meldung wird lokal erzeugt. Darum vielleicht nix im Protokoll.
Stefan
Genau da ist mein Problem, laut Monitoring ist der Server 100% auf https erreichbar, ich suche weiter…
Danke für dein Feedback.
Gerade ist Firefox 155 angekommen, schauen wir mal ob es damit besser wird.
Es zeigt sich die Tage eine Gemeinsamkeit bei den Anwendern, es passiert “immer” dann wenn eine Mail bearbeitet wird und die AI verwendet / benutzt wird.
Netzwerktechnisch können wir auch bei einem dauerhaften Ping von der Workstation auf den EGw Server keinen einzigen Paketverlust feststellen.
Ja, da ist was…
Meinst du, dass passiert, wenn Jemand anderes die KI verwendet?
Das ist auch eine Möglichkeit auf die ich noch gar nicht gekommen bin.
It habe die Webseite hier mal meinem Claude “verfüttert”:
I have one bug-report, which I would like you to look into for possible causes:
26.8.20260825 | Network Error Meldung
I’ll fetch the forum post to understand the reported issue.
Fetch(26.8.20260825 | Network Error Meldung)
⎿ Received 69.3KB (200 OK)
Fetch(26.8.20260825 | Network Error Meldung)
⎿ Received 17.5KB (200 OK)
Explore(Find AI mail compose network error source)
⎿ Backgrounded agent (↓ to manage · ctrl+o to expand)
I’ve kicked off an investigation into the codebase while I read the forum thread. I’ll report back once it’s done — the key clue so far is that the error only happens when editing a mail with the AI
feature enabled/used.
User answered Claude’s questions:
⎿ · The forum thread mentions “AI” being used/enabled during mail compose when the network error occurs. Is this the aiassistant/ directory currently sitting untracked in your working copy (per git
status), or a different AI integration (e.g. an EPL/stylite AI feature, or a third-party browser AI extension)? → It’s the AiTools app (aiassistent was a never published prototype). AiTools wrapps
Et2Textarea and Et2Htmlarea (TinyMCE) and offers text-transformations there see the Et2Ai widget
Agent(Find Et2Ai widget network error source)
⎿ Backgrounded agent (↓ to manage · ctrl+o to expand)
Launched a more targeted investigation based on your clarification (Et2Ai widget wrapping Et2Textarea/Et2Htmlarea). I’ll let the earlier (now less relevant) exploration finish too, but this one should
give the real answer. I’ll report back once it lands.
I’ll wait for both agents to finish before reporting anything.
Ran 1 shell command
I’ll wait for the two background investigations to complete before summarizing findings.
Ran 1 shell command
Two background investigations are running to pin down the cause of the “Network error” bug tied to the Et2Ai widget in mail compose. I’ll follow up with findings once they complete.
The user who wrote about the problem uses Ollama with some local AI AFAIK
Good context — I’ll pass that along to the second agent since it’s directly relevant (Ollama local backends often have long cold-start/inference times and different response semantics than cloud APIs,
which could interact badly with a request timeout).
⎿ Message queued for delivery to a86b51f9d556a925c at its next tool round.
I’ve relayed the Ollama detail to the investigating agent so it can check timeout handling and backend-selection code specifically. I’ll report back once both investigations finish.
✻ Waiting for 2 background agents to finish
Agent “Find AI mail compose network error source” finished · 3m 24s
Found a strong candidate — let me verify it directly before reporting.
Read 1 file
Confirmed — the correct pattern is on line 165. Now let me check the other two flagged occurrences (temperature/max_tokens around lines 633/635).
Read 1 file
The first investigation confirmed a concrete bug, and I verified it directly in the source. Here’s what’s going on:
Root cause found and verified: aitools/src/Bo.php:483
curl_setopt($ch, CURLOPT_TIMEOUT, $config[‘timeout’] ?? $is_translation ? 90 : 6060);
This is a PHP operator-precedence bug: ?? binds tighter than ?:, so this actually parses as ($config[‘timeout’] ?? $is_translation) ? 90 : 6060, not the intended $config[‘timeout’] ?? ($is_translation ?
90 : 60). Two things went wrong: a 60→6060 typo, and the missing parens mean any configured timeout is only used as a truthiness check, not its actual value.
Effect: for any non-translation AI action (the mail-compose “improve/fix/summarize” prompts) with no explicit per-prompt timeout, curl gets a 6060-second (101 minute) timeout. When the backend is slow —
like a local Ollama instance, which is exactly what this reporter is using — the request can run far longer than the web server’s/PHP-FPM’s/reverse-proxy’s own timeout (typically 30–60s). The proxy/PHP
kills the connection first, the browser’s fetch() never gets a real HTTP response, and EGroupware’s generic AJAX error handler (api/js/etemplate/jsapi/egw_json.ts:443) falls back to the literal
“network error” message — even though nothing is actually wrong with the network.
I confirmed the correct intended pattern exists elsewhere in the same file (line 165: $prompt[‘timeout’] ?? self::get_ai_config()[‘timeout’] ?? ($only_translation ? 90 : 60)), and found the same
precedence bug repeated at lines 633 and 635 (temperature and max_tokens), introduced in the same commit (7b9b4b32, 2026-05-21, “AiTools: allow multiple tool calls…”).
Root cause
aitools/src/Bo.php:483
curl_setopt($ch, CURLOPT_TIMEOUT, $config[‘timeout’] ?? $is_translation ? 90 : 6060);
PHP’s ?? binds tighter than ?:, so this actually parses as ($config[‘timeout’] ?? $is_translation) ? 90 : 6060 — not the intended $config[‘timeout’] ?? ($is_translation ? 90 : 60).
I traced the real call path (process_predefined_prompt() → get_predefined_prompts() with default $return_prompt=true, which returns raw prompt data, not the metadata array where a timeout gets computed)
and confirmed $config[‘timeout’] is normally unset for the standard mail-compose prompts (grammar fix, rewrite, summarize, etc.), and get_ai_config() never supplies one either. So for effectively every
non-translation AI action:
(null ?? false) → false → curl timeout = 6060 seconds (101 minutes), instead of the intended 60.
The same precedence bug is repeated at lines 633 (temperature) and 635 (max_tokens).
Why this produces “Network error” specifically with Ollama
Because curl is willing to wait 101 minutes, PHP never voluntarily gives up. When the backend is slow — a local Ollama instance is exactly this case, since local inference regularly runs past 60–90
seconds on longer mail bodies — the web server’s own timeout (php-fpm request_terminate_timeout, nginx/Apache proxy read timeout) fires first and kills the connection mid-request. The browser’s fetch()
never receives a real HTTP response, so EGroupware’s generic AJAX handler (api/js/etemplate/jsapi/egw_json.ts:443) falls back to the literal “network error” string — even though nothing is wrong with
the network. Fast cloud APIs rarely hit this because they typically respond in a few seconds, which is why the bug shows up reliably with Ollama but might look intermittent otherwise.
I also confirmed a second, independent bug: the admin-facing “Timeout” config field (aitools/templates/default/config.xet) is never actually read by get_ai_config(), so there’s no way for an admin to
work around this by raising the timeout — it’s a dead setting.
Applied all three fixes to aitools/src/Bo.php:
php -l confirms no syntax errors. Changes are uncommitted in the aitools repo (its own git remote, separate from the main egroupware checkout) — let me know if you want me to commit them.
✻ Baked for 32s · done 9:14 PM
❯ commit this with a message referencing the fix
Bitte mal Testen …
Ralf
Hört sich nachvollziehbar an, bei uns ist das Patch eingespielt, jetzt muss ich warten ob sich nochmal jemand beschwert.
Es gab keine Beschwerden mehr, das war sicher das Problem, danke @RalfBecker
