mirror of
https://github.com/Chocobozzz/PeerTube.git
synced 2026-03-02 22:57:11 -05:00
Better rate limit error message for peertube-cli #6442
Labels
No labels
Component: Accessibility
Component: Administration
Component: Auth
Component: CLI
Component: Channels
Component: Chapters
Component: Comments
Component: Custom Markdown
Component: Docker 🐳
Component: Documentation 📚
Component: Email
Component: Embed
Component: Federation 🎡
Component: Import/Export
Component: Live
Component: Metadata
Component: Mobile
Component: Moderation :godmode:
Component: Notifications
Component: Object storage
Component: Observability
Component: PeerTube Plugin 📦
Component: Player ⏯️
Component: Playlist
Component: Recommendation
Component: Redundancy
Component: Registration
Component: Runners
Component: SEO
Component: Search
Component: Security
Component: Stats
Component: Studio
Component: Studio
Component: Subscriptions
Component: Subtitles 💬
Component: Transcoding
Component: Upload
Component: Video Import
Component: i18n 🔡
Priority: High
Priority: Low
Priority: Roadmap
Status: Blocked ✋
Status: In Progress 🔜
Status: To Reproduce
Status: Waiting for answer
Template not filled
Type: Bug 🐛
Type: Discussion 💭
Type: Discussion 💭
Type: Duplicate ➿
Type: Feature Request ✨
Type: Maintenance 👷♀️
Type: Performance
Type: Question
UI
good first issue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/PeerTube#6442
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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?
Originally created by @matthijskooijman on GitHub (Feb 1, 2026).
Describe the current behavior
I am using
peertube-clito do some bulk video uploads. This caused 429 rate limit exceeded errors for me.Looking at the logs and source, it seems that after the upload the status is polled to see when the upload is completed. These are spaced 50ms apart, which mean that the default 50 requests / 10s (200ms / request) can be violated.Edit: Seems incorrect, see first comment.Here's the loop:
github.com/Chocobozzz/PeerTube@b1ed99d964/packages/server-commands/src/videos/videos-command.ts (L481-L485)Steps to reproduce
This happened for me with TS files about 500-700MB in size.
From the server log from the first upload:
Describe the expected behavior
Files should just upload.
Additional information
I would suggest fixing this by increasing the delay in the loop. I tried 250ms, which seems to fix the issue for me (at the expense of worst-case 200ms extra latency per video, which seems very acceptable).Edit: Seems incorrect, see first comment.
@matthijskooijman commented on GitHub (Feb 1, 2026):
Hm, even with the 250ms wait, I still got some sporadic 429 responses, but it seems now on the login, so maybe I'm triggering the log rate limit now:
In fact, looking back at my original log, the rate limit was on
/api/v1/oauth-clients/localwhich probably means I was triggering the log rate limit all the time. And increasing the wait time did not actually help (I think it was more related to how soon I started test attempts after each other, since the login limit is 15/5min).So I guess my suggested fix will not help. Instead, I can imagine a fix is either:
@Chocobozzz commented on GitHub (Feb 2, 2026):
Hello,
Please increase rate limits on the server: https://github.com/Chocobozzz/PeerTube/blob/develop/config/production.yaml.example#L20
@matthijskooijman commented on GitHub (Feb 2, 2026):
Thanks, I had actually raised the limit already to doublecheck that it was indeed the login rate limit that was triggered (forgot to mention that in my previous comment). Even though that is the most proper fix, I could still think that peertube-cli could be improved to make the experience more streamlined, in the two ways of the previous comment.
Maybe this issue could be reopened for that, but I can also imagine that this is not something that has any priority and leaving it closed is also fine.