Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 14:13:35 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #5093] [BUG]: Meeting Assistant transcription fails with ECONNABORTED when recording exceeds 1GB (Tinyscribe 413 Request Entity Too Large) #4910

New Issue
Closed
opened 2026-06-05 14:50:49 -04:00 by yindo · 1 comment
yindo commented 2026-06-05 14:50:49 -04:00
Owner
Copy Link
Copy Source

Originally created by @ghost on GitHub (Mar 1, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5093

How are you running AnythingLLM?

AnythingLLM desktop app

What happened?

When attempting to transcribe (or re-transcribe) a large meeting recording (~2.1GB WAV) using Meeting Assistant (Windows CUDA build), transcription fails with:

TypeError: fetch failed
[cause]: Error: write ECONNABORTED
code: 'ECONNABORTED'

From the logs it appears the failure happens during the POST request to the Tinyscribe /inference endpoint.

Manual testing shows that Tinyscribe returns:

HTTP/1.1 413 Request Entity Too Large
exceeds max_body of 1073741824

So the request is rejected because the file size exceeds waitress’ 1GB max_body limit.

As a result:

  • Transcription fails
  • Tinyscribe process is killed
  • Meeting Assistant attempts partial transcript recovery

Expected behavior:
Large recordings should either:

  • Be supported (via chunking or increased limit), or
  • Fail with a clear, user-facing error message explaining the maximum supported size.

Currently the user only sees a generic fetch failed / ECONNABORTED error.

Are there known steps to reproduce?

  1. Record a long meeting so that master-recording.wav exceeds 1GB (in my case ~2.1GB).
  2. Open Meeting Assistant.
  3. Attempt transcription or re-transcription.
  4. Observe failure with ECONNABORTED.

Manual reproduction:

Start Tinyscribe:

tinyscribe.exe --port 9090 --debug

Then send a large file:

curl -F "file=@master-recording.wav" http://localhost:9090/inference

Response:

HTTP/1.1 413 Request Entity Too Large
exceeds max_body of 1073741824

The issue appears to be caused by waitress default max_body limit (1GB).

log:

PS C:\Users\pavel\AppData\Roaming\anythingllm-desktop\storage\engines\meeting-assistant\windows-x64-cuda> .\tinyscribe.exe `
>>   --ffmpeg C:\Users\pavel\AppData\Roaming\anythingllm-desktop\storage\engines\ffmpeg\windows-x64 `
>>   -d C:\Users\pavel\AppData\Roaming\anythingllm-desktop\storage\models\meeting-assistant `
>>   --port 9090 --debug
Added ffmpeg path to environment: C:\Users\pavel\AppData\Roaming\anythingllm-desktop\storage\engines\ffmpeg\windows-x64
2026-03-01 17:21:21,206 - api.server - INFO - Starting TinyScribe API server on 0.0.0.0:9090
2026-03-01 17:21:21,212 - waitress - INFO - Serving on http://0.0.0.0:9090

PS C:\Users\pavel> curl -v -X POST http://localhost:9090/inference `
>>   -H "Content-Type: multipart/form-data" `
>>   -F "file=@C:\Users\pavel\AppData\Roaming\anythingllm-desktop\storage\meeting-assistant\9d0515cd-b873-43c5-afd1-5335e0f37a7b\master-recording.wav"
Note: Unnecessary use of -X or --request, POST is already inferred.
* Host localhost:9090 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:9090...
*   Trying 127.0.0.1:9090...
* Established connection to localhost (127.0.0.1 port 9090) from 127.0.0.1 port 8459
* using HTTP/1.x
> POST /inference HTTP/1.1
> Host: localhost:9090
> User-Agent: curl/8.18.0
> Accept: */*
> Content-Length: 2136645388
> Content-Type: multipart/form-data; boundary=------------------------BXxuuxIu9YF4dHWSGXAMOM
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
<
< HTTP/1.1 413 Request Entity Too Large
< Connection: close
< Content-Length: 85
< Content-Type: text/plain; charset=utf-8
< Date: Sun, 01 Mar 2026 14:21:49 GMT
< Server: waitress
<
Request Entity Too Large

exceeds max_body of 1073741824

(generated by waitress)* we are done reading and this is set to close, stop send
* abort upload after having sent 1074397184 bytes
* shutting down connection #0
Originally created by @ghost on GitHub (Mar 1, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5093 ### How are you running AnythingLLM? AnythingLLM desktop app ### What happened? When attempting to transcribe (or re-transcribe) a large meeting recording (~2.1GB WAV) using Meeting Assistant (Windows CUDA build), transcription fails with: ``` TypeError: fetch failed [cause]: Error: write ECONNABORTED code: 'ECONNABORTED' ``` From the logs it appears the failure happens during the POST request to the Tinyscribe `/inference` endpoint. Manual testing shows that Tinyscribe returns: ``` HTTP/1.1 413 Request Entity Too Large exceeds max_body of 1073741824 ``` So the request is rejected because the file size exceeds waitress’ 1GB `max_body` limit. As a result: - Transcription fails - Tinyscribe process is killed - Meeting Assistant attempts partial transcript recovery **Expected behavior:** Large recordings should either: - Be supported (via chunking or increased limit), or - Fail with a clear, user-facing error message explaining the maximum supported size. Currently the user only sees a generic `fetch failed / ECONNABORTED` error. ### Are there known steps to reproduce? 1. Record a long meeting so that `master-recording.wav` exceeds 1GB (in my case ~2.1GB). 2. Open Meeting Assistant. 3. Attempt transcription or re-transcription. 4. Observe failure with `ECONNABORTED`. Manual reproduction: Start Tinyscribe: ``` tinyscribe.exe --port 9090 --debug ``` Then send a large file: ``` curl -F "file=@master-recording.wav" http://localhost:9090/inference ``` Response: ``` HTTP/1.1 413 Request Entity Too Large exceeds max_body of 1073741824 ``` The issue appears to be caused by waitress default `max_body` limit (1GB). log: ``` PS C:\Users\pavel\AppData\Roaming\anythingllm-desktop\storage\engines\meeting-assistant\windows-x64-cuda> .\tinyscribe.exe ` >> --ffmpeg C:\Users\pavel\AppData\Roaming\anythingllm-desktop\storage\engines\ffmpeg\windows-x64 ` >> -d C:\Users\pavel\AppData\Roaming\anythingllm-desktop\storage\models\meeting-assistant ` >> --port 9090 --debug Added ffmpeg path to environment: C:\Users\pavel\AppData\Roaming\anythingllm-desktop\storage\engines\ffmpeg\windows-x64 2026-03-01 17:21:21,206 - api.server - INFO - Starting TinyScribe API server on 0.0.0.0:9090 2026-03-01 17:21:21,212 - waitress - INFO - Serving on http://0.0.0.0:9090 PS C:\Users\pavel> curl -v -X POST http://localhost:9090/inference ` >> -H "Content-Type: multipart/form-data" ` >> -F "file=@C:\Users\pavel\AppData\Roaming\anythingllm-desktop\storage\meeting-assistant\9d0515cd-b873-43c5-afd1-5335e0f37a7b\master-recording.wav" Note: Unnecessary use of -X or --request, POST is already inferred. * Host localhost:9090 was resolved. * IPv6: ::1 * IPv4: 127.0.0.1 * Trying [::1]:9090... * Trying 127.0.0.1:9090... * Established connection to localhost (127.0.0.1 port 9090) from 127.0.0.1 port 8459 * using HTTP/1.x > POST /inference HTTP/1.1 > Host: localhost:9090 > User-Agent: curl/8.18.0 > Accept: */* > Content-Length: 2136645388 > Content-Type: multipart/form-data; boundary=------------------------BXxuuxIu9YF4dHWSGXAMOM > Expect: 100-continue > < HTTP/1.1 100 Continue < < HTTP/1.1 413 Request Entity Too Large < Connection: close < Content-Length: 85 < Content-Type: text/plain; charset=utf-8 < Date: Sun, 01 Mar 2026 14:21:49 GMT < Server: waitress < Request Entity Too Large exceeds max_body of 1073741824 (generated by waitress)* we are done reading and this is set to close, stop send * abort upload after having sent 1074397184 bytes * shutting down connection #0 ```
yindo added the possible bug label 2026-06-05 14:50:49 -04:00
yindo closed this issue 2026-06-05 14:50:49 -04:00
yindo commented 2026-06-05 14:50:49 -04:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Mar 2, 2026):

In 1.11.1 we are releasing a new version of MA (0.0.3) that removes this limitation so it should not longer be an issue

<!-- gh-comment-id:3985194350 --> @timothycarambat commented on GitHub (Mar 2, 2026): In 1.11.1 we are releasing a new version of MA (0.0.3) that removes this limitation so it should not longer be an issue
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label possible bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#4910
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?