Limits
Every limit here reports itself rather than failing silently. These are the numbers to plan around.
#Every limit
Limit | Value | What happens |
|---|---|---|
Branches | only the first 100 are ever fetched | /repos/{repo}/branches?per_page=100 with no Link-header pagination follow. |
Directory listings are not paginated | - | /repos/{repo}/contents/{path} is a single unpaginated call, so very large folders may be listed incompletely. |
Repository listing | 100 per page | GET /user/repos with per_page=100. |
Public repository search | first page only | Search runs only when a query is typed and page === 1. Paging past page 1 shows only the person's own repositories. |
Auto-convert | maximum 10 path segments after the ref | The matcher list covers a ref plus 1 to 10 further segments. Deeper file paths do not auto-convert. |
Image rendering capped at 800px tall | - | - |
Code viewer capped at 600px tall | - | - |
Markdown switches to virtualised rendering a | - | - |
Connect polling gives up after 30 seconds | - | - |
No rate-limit handling anywhere | - | There is no retry, no backoff and no Retry-After handling in the capability. A GitHub 403 caused by rate limiting is classified as an access error and reported to the reader as though nobody has access. |
File content passes through the server as a | - | Large files can therefore be slow or fail. |
#A few things worth knowing
A limit that is reached is reported in the interface, not in a log you have to find.
Limits are per site or per tenant depending on the limit. The table says which.
Edition can change some of these.
#Related
They announce themselves. Read the message.
