Show actual disk size instead of size spec in resize command#51
Merged
ret2libc merged 2 commits intotrailofbits:mainfrom Mar 24, 2026
Merged
Conversation
After a --no-disk resize, `dropkit resize` showed the size spec's disk (e.g. 80 GB for s-2vcpu-4gb) instead of the droplet's actual disk (25 GB). This is confusing for users planning temporary scale-ups — they need to see their real disk to know if they can scale back down. Read disk from `droplet["disk"]` (actual allocation) instead of `droplet["size"]["disk"]` (what the size tier offers). When the two differ, show an inline hint: "25 GB (size spec: 80 GB, disk was not resized)" so the situation is immediately clear. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
Author
|
AI Assistant: |
Read all three resource fields from the droplet object directly (droplet["vcpus"], droplet["memory"], droplet["disk"]) instead of from the size spec (droplet["size"]["vcpus"], etc.). After a --no-disk resize these can diverge — the size spec reflects the new tier while the droplet retains its original resources. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ret2libc
approved these changes
Mar 24, 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.
Summary
AI Agent with Greg: We resized a droplet with
--no-diskto keep the option to scale back down, then randropkit resizeagain and saw "Disk: 80 GB" — which made us briefly question our own sanity. Turns out the resize display was reading the size spec instead of the actual disk. Reality check restored. 🔍💾The bug: After a
--no-diskresize (e.g.,s-1vcpu-1gb→s-2vcpu-4gb), the resize command showed disk fromdroplet["size"]["disk"](80 GB — what the size tier offers) instead ofdroplet["disk"](25 GB — what the droplet actually has).The fix: Read from
droplet["disk"](actual allocation). When actual disk differs from size spec, show an inline hint so the situation is immediately clear:vs. previously misleading:
This matters most for users doing temporary CPU/RAM scale-ups who need to confirm their disk is still at the original size before scaling back down.
Test plan
uv run ruff check dropkit/main.py— passeduv run ruff format --check dropkit/main.py— passeduv run ty check dropkit/main.py— passeduv run pytest tests/ -v— 288 passed (1 pre-existing failure in test_rename unrelated to this change)dropkit resize <name>after a--no-diskresize — verify actual disk shown with hintdropkit resize <name>on a droplet where disk matches spec — verify no hint shown🤖 Generated with Claude Code — your friendly AI that believes in showing users the truth, the whole truth, and nothing but the disk truth
Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com