docs(service-delete): document async deletion behavior#58
Conversation
A successful 'service delete' schedules removal asynchronously — the service typically continues to appear in 'service list' as Status=SUSPENDED for some time. Re-issuing the delete returns 'Resource already exists ... service deletion already scheduled or service not found', which means the first delete worked. To verify actual removal, query 'service get --id <id>' (returns 'service not found' once gone) rather than waiting for 'service list' to update. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 58 minutes and 41 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Adds a "Behavior to be aware of" section to
zeabur-service-deletedocumenting three properties of the CLI's delete that are easy to misread as failures:Deletion is async. A successful
service deleteschedules removal — the service typically continues to appear inservice listasStatus=SUSPENDEDfor some time before eventual consistency clears it. The skill currently implies delete is immediate, which led me to conclude the delete had failed when the service was still in the list.Retrying a delete errors with 'already scheduled', not because it failed. The CLI returns:
```
ERROR delete service failed: Message: Resource already exists, ...
description:service deletion already scheduled or service not found
```
The error is misleading — it actually confirms the first delete worked. Documenting this so agents don't loop trying to "fix" a successful delete.
service get --id <id>is the way to confirm actual removal — it returns "service not found" once the service is gone, whileservice listmay still show it for minutes due to lag.Test plan
service delete -y -i=falsewith success exit, but service appeared inservice listfor several minutes after withStatus=SUSPENDEDservice get --id <id>returns "service not found" once removal completes, whileservice listwas still lagging🤖 Generated with Claude Code