Possible Copilot follow-up question issue (due to note names)?

[GitTimeraider]

Description

Good day,
Ive been trying out the Github Copilot LLM in Trilium and while mostly working fine, it seems to have issues whereby the first question it goes well but then it probably auto-renames a chatfile and follow-up questions cannot be saved with error 400 (hash mismatch!)

Basically, first question is fine. Second question
website shows:
/api/notes/8psDV8Qr0B62/data 400 (Bad Request)
toast-CFBZ78i6.js:2 13:33:04 error: Status code: 400
URL: PUT notes/8psDV8Qr0B62/data
Message: -
content_renderer-DcYoX44w.js:2 13:33:04 400 PUT notes/8psDV8Qr0B62/data -
SidebarChat-POSMiyNa.js:1 Failed to save chat:

I then looked in the docker log and:
Created new note 'TAjFAkx1Ryaq', branch 'nGwZxG12Fm72_TAjFAkx1Ryaq' of type 'llmChat', mime 'application/json'
200 GET /api/special-notes/get-or-create-llm-chat with 363 bytes took 6ms
200 POST /api/tree/load with 5156 bytes took 0ms
JS Error: Uncaught error: Message: ResizeObserver loop completed with undelivered notifications., URL: https://SITENAME/#root/A9LvjfniwQe4/qH9FfTnPvpr5/bJ4MbW6dPObI?ntxId=NGFdoc, Line: 0, Column: 0, Error object: null, Stack: null
Stack: Error
at Object.logError$1 [as logError] (https://SITENAME/src/content_renderer-DcYoX44w.js:2:27134)
at Y.window.onerror (https://SITENAME/src/glob-BFlqWLGV.js:1:37136)
JS Error: Uncaught error: Message: ResizeObserver loop completed with undelivered notifications., URL: https://SITENAME/#root/A9LvjfniwQe4/qH9FfTnPvpr5/bJ4MbW6dPObI?ntxId=NGFdoc, Line: 0, Column: 0, Error object: null, Stack: null
Stack: Error
at Object.logError$1 [as logError] (https://SITENAME/src/content_renderer-DcYoX44w.js:2:27134)
at Y.window.onerror (https://SITENAME/src/glob-BFlqWLGV.js:1:37136)
JS Error: Uncaught error: Message: ResizeObserver loop completed with undelivered notifications., URL: https://SITENAME/#root/A9LvjfniwQe4/qH9FfTnPvpr5/bJ4MbW6dPObI?ntxId=NGFdoc, Line: 0, Column: 0, Error object: null, Stack: null
Stack: Error
at Object.logError$1 [as logError] (https://SITENAME/src/content_renderer-DcYoX44w.js:2:27134)
at Y.window.onerror (https://SITENAME/src/glob-BFlqWLGV.js:1:37136)
Naming chat note TAjFAkx1Ryaq with the copilot-agent provider.
204 PUT /api/notes/TAjFAkx1Ryaq/data with 0 bytes took 3ms
Auto-renamed chat note TAjFAkx1Ryaq to "What happened Monday"
200 GET /api/health-check with 15 bytes took 0ms
JS Error: 400 PUT notes/TAjFAkx1Ryaq/data -
Stack: Error
at logError$1 (https://SITENAME/src/content_renderer-DcYoX44w.js:2:27134)
at D (https://SITENAME/src/server-DHohsnQe.js:2:3815)
at async Object.error (https://SITENAME/src/server-DHohsnQe.js:2:2796)

Looks like the first message creates a log, but the second message already cant save it in there anymore. So any follow-up question disappears after answering and it generated errors which show up as notifications as well

TriliumNext Version

0.105.0 (database: 240, sync protocol: 39) Build: 19.08.2026, 20:07:34, revision: a0908a6

What operating system are you using?

Other (specify below)

What is your setup?

Local + server sync

Operating System Version

Docker

Error logs

Created new note 'TAjFAkx1Ryaq', branch 'nGwZxG12Fm72_TAjFAkx1Ryaq' of type 'llmChat', mime 'application/json'
200 GET /api/special-notes/get-or-create-llm-chat with 363 bytes took 6ms
200 POST /api/tree/load with 5156 bytes took 0ms
JS Error: Uncaught error: Message: ResizeObserver loop completed with undelivered notifications., URL: https://SITENAME/#root/A9LvjfniwQe4/qH9FfTnPvpr5/bJ4MbW6dPObI?ntxId=NGFdoc, Line: 0, Column: 0, Error object: null, Stack: null
Stack: Error
at Object.logError$1 [as logError] (https://SITENAME/src/content_renderer-DcYoX44w.js:2:27134)
at Y.window.onerror (https://SITENAME/src/glob-BFlqWLGV.js:1:37136)
JS Error: Uncaught error: Message: ResizeObserver loop completed with undelivered notifications., URL: https://SITENAME/#root/A9LvjfniwQe4/qH9FfTnPvpr5/bJ4MbW6dPObI?ntxId=NGFdoc, Line: 0, Column: 0, Error object: null, Stack: null
Stack: Error
at Object.logError$1 [as logError] (https://SITENAME/src/content_renderer-DcYoX44w.js:2:27134)
at Y.window.onerror (https://SITENAME/src/glob-BFlqWLGV.js:1:37136)
JS Error: Uncaught error: Message: ResizeObserver loop completed with undelivered notifications., URL: https://SITENAME/#root/A9LvjfniwQe4/qH9FfTnPvpr5/bJ4MbW6dPObI?ntxId=NGFdoc, Line: 0, Column: 0, Error object: null, Stack: null
Stack: Error
at Object.logError$1 [as logError] (https://SITENAME/src/content_renderer-DcYoX44w.js:2:27134)
at Y.window.onerror (https://SITENAME/src/glob-BFlqWLGV.js:1:37136)
Naming chat note TAjFAkx1Ryaq with the copilot-agent provider.
204 PUT /api/notes/TAjFAkx1Ryaq/data with 0 bytes took 3ms
Auto-renamed chat note TAjFAkx1Ryaq to "What happened Monday"
200 GET /api/health-check with 15 bytes took 0ms
JS Error: 400 PUT notes/TAjFAkx1Ryaq/data -
Stack: Error
at logError$1 (https://SITENAME/src/content_renderer-DcYoX44w.js:2:27134)
at D (https://SITENAME/src/server-DHohsnQe.js:2:3815)
at async Object.error (https://SITENAME/src/server-DHohsnQe.js:2:2796)

[dosubot[bot]]

Hi @GitTimeraider! I'm Dosu and I'm helping the TriliumNext team.

This looks like a race condition between the chat's auto-rename and the sidebar's content save. Here's what the code shows:

The conflict between auto-rename and the pending save

1. Your first message creates the chat note (e.g. TAjFAkx1Ryaq) and the LLM reply streams in.
2. After the first turn, generateChatTitle fires on the server. It sets note.title = title and calls note.save(), which updates the note's internal state (blobId/utcDateModified) on the server [1].
3. Meanwhile, the sidebar's useSpacedUpdate callback has a pending debounced save — it calls server.put("notes/${noteId}/data", ...) with the chat content [2].
4. When that PUT arrives, the server sees a stale client state (the rename already bumped the note) and rejects it with a 400.

Your log confirms this sequence exactly:

204 PUT /api/notes/TAjFAkx1Ryaq/data   ← first content save succeeds
Auto-renamed chat note TAjFAkx1Ryaq to "What happened Monday"  ← rename bumps server state
JS Error: 400 PUT notes/TAjFAkx1Ryaq/data  ← next content save is rejected (stale)

Why the sidebar is vulnerable: The SidebarChat component intentionally uses a plain useSpacedUpdate with a raw server.put instead of the useEditorSpacedUpdate that other editor widgets use, because it creates notes lazily and doesn't have an FNote reference available [3]. The trade-off is that it has no mechanism to absorb server-side changes (like the rename) before its next write, so the second PUT conflicts.

This isn't specific to the Copilot provider per se — all providers go through generateChatTitle [4] — but the timing of when the title generation completes relative to the debounced save determines whether the collision hits. Different providers may return titles at different speeds, making it more or less reproducible.

Workaround for now: Refreshing the page after the first message (before sending a second) may help avoid the error, though it's not ideal.

The root fix would need the sidebar's save path to either re-fetch the note's current state before writing, or coordinate with generateChatTitle so the rename and content save don't race. The relevant code is in SidebarChat.tsx (lines 77–88) and chat_title.ts (lines 49–51).

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[eliandoran]

Hi,

Are you using a reverse proxy by any chance? And if so, what version?

[GitTimeraider]

Hi,

Are you using a reverse proxy by any chance? And if so, what version?

Based on the errors im not sure if it has anything to do with it, but for ease I do use nginx 1.30.4,3

[eliandoran]

@GitTimeraider ,

The key is this part of the error:

JS Error: 400 PUT notes/TAjFAkx1Ryaq/data -

The 400 error can come from somewhere in the environment, that's why I suspected the reverse proxy.

Might be worth to check:

• Consider increasing client_max_body_size, since the response can be too big to fit with the default of 1MB if it wasn't changed.
• It would help to check the request: Inspect Element -> Network -> look for the failing /data request and post a picture of the headers and the response.

[GitTimeraider]

Sure, was focussed on the renaming part as the logging shows it first creating a randomized name, then renaming the note to the first question asked and then failing to save the second question using the non-renamed name.
Why does it even need to rename the note it apparently uses to save previous chat anyway, not sure what that adds to the ai chat.

Anyway, never know what influences it so will check it out.
Set the bodysize to 200m to be safe.

Will check what exactly is going in the network tab of the dev tools first thing tomorrow morning, need to get some sleep.

Will also see what happens when I go to it with IP
(just in case someone wonders why thats not the first thing I test.. I like overkill in security meaning both my OIDC as well as my firewall will not allow me to get to any of my applications without going through reverse proxy XD .. so need to turn off some firewall rules and adjust the OIDC to do such a simple test XD)

[eliandoran]

@GitTimeraider ,

Chat conversations start with the date and then the first message is processed to generate a short title (via a cheap model of the same AI provider). This makes the conversation easy to spot instead of many date-based conversations.

The rename is a red herring, it doesn't cause any issues even if it fails (and in your case it succeeded).

The 400 you are seeing happens when the server tries to save the conversation, which happens at every step.

@dosubot, take notes. The rename cannot possibly cause 400, there is no such thing as a "stale" client state.

[dosubot[bot]]

Noted and appreciated, @eliandoran — thanks for the correction. I was wrong to suggest a stale-state conflict. Looking at the code, updateNoteData does a straightforward note.setContent() with no precondition check [1], so the rename cannot cause a 400.

@GitTimeraider, the maintainer's direction is the right one: the 400 is most likely nginx rejecting the request body before it even reaches Trilium. The sidebar chat saves the full message history as a single JSON blob via server.put(notes/${noteId}/data, { content: JSON.stringify(content) }) [2], so by the second or third exchange the payload can easily exceed nginx's default client_max_body_size of 1 MB. Setting it to something like client_max_body_size 50m; in your nginx config and reloading should resolve it. When you check the network tab, look at the failing /data request's response body — an nginx 400 error page (rather than a Trilium JSON error) would confirm this.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[GitTimeraider]

Request URL
https://SITENAME/api/llm-chat/stream
Request Method
POST
Status Code
400 Bad Request
Remote Address
192.168.3.1:443 <- nginx IP
Referrer Policy
no-referrer
content-security-policy
default-src 'self'; script-src 'unsafe-inline' 'self'; img-src data: 'self' https://.SITENAME; style-src 'unsafe-inline' 'self'; media-src 'self'; font-src data: 'self' https://esm.sh; frame-src 'self'; frame-ancestors 'self'; form-action 'self'; connect-src https://api.github.com https://.SITENAME wss://*.SITENAME; worker-src 'self';
date
Fri, 21 Aug 2026 06:37:53 GMT
permissions-policy
accelerometer=(), autoplay=(), camera=(), display-capture=(), document-domain=(), fullscreen=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), midi=(), payment=(), picture-in-picture=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()
referrer-policy
no-referrer
strict-transport-security
max-age=63072000; includeSubDomains
x-content-type-options
nosniff
x-xss-protection
0
:authority
SITENAME
:method
POST
:path
/api/llm-chat/stream
:scheme
https
accept
/
accept-encoding
gzip, deflate, br, zstd
accept-language
en-US,en-NL;q=0.9,en;q=0.8
cache-control
no-cache
content-length
597
content-type
application/json
dnt
1
origin
https://SITENAME.com
pragma
no-cache
priority
u=1, i
sec-ch-ua
"Not;A=Brand";v="8", "Chromium";v="150", "Microsoft Edge";v="150"
sec-ch-ua-mobile
?0
sec-ch-ua-platform
"Windows"
sec-fetch-dest
empty
sec-fetch-mode
cors
sec-fetch-site
same-origin
trilium-component-id
trilium-hoisted-note-id
root
trilium-local-now-datetime
2026-08-21 08:37:53.236+0200
trilium-setup-auth
null
user-agent
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36
x-csrf-token
8191f07b9c64ecc90db9abcee3e8aa93bed08ed86775dea9181b23cca1a3baeb.a3d099ff3a5057f895359cc0b3b0e8626b03a2531e28fc683b033049aeee38be

400 error that shows up in the network tab.

[GitTimeraider]

Skipped the nginx and went directly by IP after having allowed that.
No issues when its just through IP so it is somewhere in the nginx .. checking if I can find where it goes wrong.

[GitTimeraider]

Ok, turns out it was upgrade connection and websocket causing issues. However as those are needed for Trilium, I had the choice between having trilium work or the chat work, not both at the same time with the same nginx settings.
So while keeping the settings for nginx for general Trilium the same, I created a separate nginx location with some settings adjusted so only the LLM chat would use these nginx settings, not the entirity of Trilium.

Using the NGINX plugin in OPNSense btw.
In the nginx plugin UI you can duplicate the location you use for Trilium, set URL pattern to /api/llm-chat/stream, set match type to dont check regex on longest prefix and disable websockets. Then adjust the https server for Trillium to make use of that location as well as your main old one.

Or in nginx config terms

location ^~ /api/llm-chat/stream {
client_max_body_size 50m;
proxy_set_header Host $host;
proxy_set_header X-TLS-Cipher $ssl_cipher;
proxy_set_header X-TLS-Protocol $ssl_protocol;
proxy_set_header X-TLS-SNI-Host $ssl_server_name;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-TLS-Client-Intercepted $tls_intercepted;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
proxy_ignore_client_abort off;
proxy_request_buffering off;
proxy_max_temp_file_size 1024m;
proxy_buffering off;
proxy_pass http://upstreamXXXXXXXXXXXXXXXXXX;
proxy_hide_header X-Powered-By;
proxy_hide_header Referrer-Policy;
proxy_hide_header X-XSS-Protection;
proxy_hide_header X-Content-Type-Options;
proxy_hide_header Strict-Transport-Security;
proxy_hide_header Content-Security-Policy;
proxy_hide_header Content-Security-Policy-Report-Only;
}

So now my Trilium uses my normal nginx settings while specifically the LLM chat uses different ones. So now both of them work fine.
Will keep an eye out on how it looks even after stuff like cookies and lingering connections get refreshed but think this resolved it for me.