Repository navigation
bl apps: explain the app limit and say it counts every workspace - #45
Merged
Merged
Conversation
When an account is at its app limit, the CLI now says plainly that nothing changed and points to `bl apps list --scope owned --include-deleted` as the next step, unless the server supplies its own next_action. `bl apps delete --help` told agents to "explicitly retry cleanup" when capacity stays held, but no client command does that; the server retries on its own. The help now says so. Co-authored-by: eggy <efcb1558faef42d4f7318ed532141edb57bcc52dbc8a92ae8c35637b8a5c3ff6@remote-agent-pilot.communities.buzz.xyz> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: eggy <efcb1558faef42d4f7318ed532141edb57bcc52dbc8a92ae8c35637b8a5c3ff6@remote-agent-pilot.communities.buzz.xyz> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The control plane always sends its own next_action for owner_site_limit_reached, and the server's step wins over the CLI's, so the note that the allowance counts every workspace never printed against a real server. Move it into the explanation, which always prints. Co-authored-by: Irving B <6c4c50b3b6dee89feaca78ea87eb5c8fde651d2d7b39d6da8c9354ce7a34e313@remote-agent-pilot.communities.buzz.xyz> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Suggest plain `bl apps list --scope owned` in the explanation, since the owned listing already shows apps still being cleaned up and its quota usage is the authoritative count. Say that every environment of an app must be deleted to free its place, and drop the claim that no command can force cleanup. Co-authored-by: Irving B <6c4c50b3b6dee89feaca78ea87eb5c8fde651d2d7b39d6da8c9354ce7a34e313@remote-agent-pilot.communities.buzz.xyz> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
nathan-thillairajah
marked this pull request as draft
November 3, 2026 23:07
kalvinnchau
reviewed
Nov 3, 2026
kalvinnchau
left a comment
kalvinnchau
left a comment
There was a problem hiding this comment.
🤖 One documentation inconsistency remains in the cleanup recovery guidance.
| retired while artifacts may be retained. Capacity remains held when \ | ||
| quota_cleanup_pending is true; explicitly retry cleanup and verify \ | ||
| authoritative usage instead of subtracting a slot locally. \ | ||
| quota_cleanup_pending is true; the server retries that cleanup on its \ |
There was a problem hiding this comment.
🤖 [P3] Keep the cleanup recovery instructions consistent. This help text now tells users that the server retries cleanup automatically, while README.md:206–211 still instructs them to explicitly retry cleanup until release. For quota_cleanup_pending: true, those describe different user actions. Update the README alongside this change to describe automatic retries and rechecking quota; consider directing users to support when cleanup remains pending, since reservation_mismatch requires operator intervention.
Contributor
Author
There was a problem hiding this comment.
🤖 Fixed in 4c67a51. The README now says the server retries cleanup on its own, so there's nothing to rerun: recheck usage with bl apps list --scope owned --include-deleted --json, and ask the BuilderLab team if cleanup stays pending, since some cases need an operator. The delete help says the same.
kalvinnchau
previously approved these changes
Nov 3, 2026
kalvinnchau
left a comment
kalvinnchau
left a comment
There was a problem hiding this comment.
🤖 Approved. The previously noted P3 cleanup-documentation inconsistency remains nonblocking.
A user is in one workspace at a time, so "every workspace" read oddly. Co-authored-by: Irving B <6c4c50b3b6dee89feaca78ea87eb5c8fde651d2d7b39d6da8c9354ce7a34e313@remote-agent-pilot.communities.buzz.xyz> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Nathan Thillairajah <nthillairajah@squareup.com>
Apps left in a previous workspace can't be acted on until they move with their owner, so the limit text no longer mentions them. The README now says the server retries quota cleanup on its own and to ask the BuilderLab team if it stays pending, matching the delete help. Co-authored-by: Irving B <6c4c50b3b6dee89feaca78ea87eb5c8fde651d2d7b39d6da8c9354ce7a34e313@remote-agent-pilot.communities.buzz.xyz> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Nathan Thillairajah <nthillairajah@squareup.com>
The fallback step now uses --include-deleted, so a deleted app whose cleanup is pending stays visible. Usage is described as shown when available, and the delete help wraps like the lines around it. Co-authored-by: Irving B <6c4c50b3b6dee89feaca78ea87eb5c8fde651d2d7b39d6da8c9354ce7a34e313@remote-agent-pilot.communities.buzz.xyz> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Nathan Thillairajah <nthillairajah@squareup.com>
nathan-thillairajah
marked this pull request as ready for review
November 3, 2026 23:21
kalvinnchau
approved these changes
Nov 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
When someone hits their app limit,
blprinted only the error code and the server's generic next step, so it wasn't clear whether anything had broken or what to do (BOT-2573). Separately,bl apps delete --helpand the README told users to "explicitly retry cleanup" when capacity stays held after a delete, but no command does that. The server retries it on its own.What changes
owner_site_limit_reached,blsays nothing was changed, existing apps keep working, andbl apps list --scope ownedshows your apps and, when available, usage. This line prints even when the server sends its own next step, which the real control plane always does.blsuggests deleting every environment of an unneeded app and checking usage again with--include-deletedbefore retrying.bl apps delete --helpand the README say the server retries quota cleanup by itself, and to ask the BuilderLab team if it stays pending, since some cases need an operator.Testing
just cipasses. By hand, a locally builtbl apps createagainst a locally run control plane from main (enforcement on, owner at the limit) printed:The delete path with cleanup still pending wasn't exercised by hand.
Risk
Message, help and README text only. JSON error codes and fields are unchanged.
🤖 Generated with Claude Code