chore: release v1.0.0-dev.1#828
Conversation
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
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 11 minutes and 0 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: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
✨ 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 |
|
✅ Review complete (commit 89a4b8f) |
|
Why is the changelog going back to v0.8 when v0.9.3 is the most recent release?
|
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Code Review
Release chore PR bumping to 1.0.0-dev.1 with a comprehensive CHANGELOG.md. All four Claude nitpicks are verified accurate against the file — duplicated PR references across sections, missing [Unreleased] section, tag-only link instead of compare link, and inconsistent PR references on some Fixed entries. Codex correctly found no defects in the release metadata itself.
Reviewed commit: 89a4b8f
💬 4 nitpick(s)
| - Classify DAPI transport errors and decode gRPC domain errors (#766) | ||
| - Detect 401 auth errors and show actionable credential message (#783) | ||
| - Throttle system theme detection to prevent white flash (#781) | ||
| - UI repaint only when needed to reduce CPU usage (#344) |
There was a problem hiding this comment.
💬 Nitpick: Several PRs appear in multiple sections
Six PR numbers are listed in more than one section, which makes the changelog harder to scan and inflates the perceived scope of each section:
- fix: repaint UI only when needed #344: Fixed line 158 (
UI repaint only when needed to reduce CPU usage) and Performance line 244 (Repaint UI only when needed, reducing idle CPU usage). - fix(ui): throttle system theme detection to prevent white flash #781: Fixed line 157 (
Throttle system theme detection to prevent white flash) and Performance line 247. - fix: settings are read from db multiple times a second #420: Fixed line 182 (
Settings read from DB 20 times a second) and Performance line 248 (Cache settings reads to avoid 20 queries per second). - fix(db): add indexes, transaction atomicity, and N+1 query elimination #549: Fixed line 176 (
Add indexes, transaction atomicity, and N+1 query elimination) and Performance line 246 (Add database indexes and eliminate N+1 queries). - feat(security): add Secret type with zeroize-on-drop and PasswordInput component #709: Added line 56 (
Secret type with zeroize-on-drop and PasswordInput component) and Security line 236. - fix: replace expect()/unwrap() panics with error propagation #562: Fixed line 199 (
Replace 50+ panicking unwrap/expect calls...) and Security line 239.
Place each PR under the single section that best describes its primary intent (e.g. #344/#781/#420/#549 under Performance only; #709/#562 under Security only) and drop the duplicate entry from Fixed/Added.
source: ['claude']
|
|
||
| ## [1.0.0-dev.1] - 2026-04-16 |
There was a problem hiding this comment.
💬 Nitpick: Missing [Unreleased] section
The file declares adherence to Keep a Changelog 1.1.0 on line 5, which calls for an ## [Unreleased] section at the top to collect in-flight entries between releases. Since v1.0-dev will continue to accumulate changes before the final v1.0.0 tag, adding this section now makes it easier to append entries as PRs land instead of reconstructing them at release time.
💡 Suggested change
| ## [1.0.0-dev.1] - 2026-04-16 | |
| ## [Unreleased] | |
| ## [1.0.0-dev.1] - 2026-04-16 |
source: ['claude']
| - Cache settings reads to avoid 20 queries per second (#420) | ||
| - Optimize x86-64 builds for base x86-64 CPU (#267) | ||
|
|
||
| [1.0.0-dev.1]: https://github.com/dashpay/dash-evo-tool/releases/tag/v1.0.0-dev.1 |
There was a problem hiding this comment.
💬 Nitpick: Reference link points to tag, not compare URL
The Keep a Changelog convention is to link versions to GitHub compare URLs so readers can diff between releases. The current link points only to the release tag, which shows the tag page but not the changes relative to the previous release. Since this changelog covers a large span since v0.8.5, a compare link is especially useful here.
💡 Suggested change
| [1.0.0-dev.1]: https://github.com/dashpay/dash-evo-tool/releases/tag/v1.0.0-dev.1 | |
| [1.0.0-dev.1]: https://github.com/dashpay/dash-evo-tool/compare/v0.8.5...v1.0.0-dev.1 |
source: ['claude']
| - Token reorder assignment and distribution field checks (#535) | ||
| - Token balance decimals (#379) | ||
| - Token purchasability not refreshing unless app restart (#432) | ||
| - Token action buttons alignment and spacing fixes |
There was a problem hiding this comment.
💬 Nitpick: Several Fixed entries lack PR references
Most entries in the changelog include a (#NNN) reference, but nine do not, which makes them stand out as inconsistent and harder to trace:
- Line 125:
Token action buttons alignment and spacing fixes - Line 129:
Confirm token pause had incorrect message - Line 132:
Fetching forever when searching for non-existent contract in add token screen - Line 139:
Confirmation dialog on withdrawal screen always showing "loading" - Line 167:
Screen button labels display hard to see in dark mode - Line 168:
Unable to click anything except back button in success screens - Line 178:
Refresh receive dialog balances from wallet on each frame - Line 196:
Remove automatic network fallback behavior to prevent silent mainnet fallback - Line 245:
Parallelize contact profile/username fetching with chunked join_all
If these correspond to merged PRs or commits, add the references; if they were direct commits with no PR, leaving them is fine but worth a quick pass to confirm.
source: ['claude']
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Code Review
Release-only PR bumping version to 1.0.0-dev.1 with CHANGELOG and Flatpak metainfo updates. No source code changes; no blocking issues. Findings are minor documentation observations: stale release date, redundant manual edit of a CI-synced field, and a few duplicate-flavored CHANGELOG entries.
Reviewed commit: 89a4b8f
Fresh dispatcher run for this queue item. A same-SHA review already existed, so this records the fresh verification without duplicating inline threads.
Code Review
Reviewed commit: 89a4b8f
🟡 1 suggestion(s) | 💬 3 nitpick(s)
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `CHANGELOG.md`:
- [SUGGESTION] line 8: Release date 2026-04-16 is stale
Today is 2026-05-09 but the CHANGELOG entry is dated 2026-04-16 — about three weeks earlier. Keep a Changelog convention is to use the actual release/tag date. Update the date to match the merge/tag day so the entry reflects when the release was actually cut. The Flatpak metainfo on line 48 carries the same date, but per the comment at metainfo.xml:46 that file is auto-synced from Cargo.toml + build date by CI — so CHANGELOG.md is the source of truth here.
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Code Review
Release-chore PR bumping to 1.0.0-dev.1 and adding a 474-commit changelog. Verification confirms three real packaging defects: the GUI binaries (Linux/Windows/macOS ARM64/Flatpak) are built without --features mcp, and the x86_64 macOS build only enables cli instead of headless. As a result, several shipped artifacts cannot run the MCP server functionality the changelog explicitly advertises (#773). Changelog format observations are minor.
Reviewed commit: 89a4b8f
🔴 4 blocking | 💬 4 nitpick(s)
4 additional findings
🔴 blocking: GUI binaries built without the `mcp` feature on Linux/Windows
.github/workflows/release.yml (lines 97-100)
src/lib.rs:13 gates the entire mcp module on cfg(any(feature = "mcp", feature = "cli")), and src/app.rs:427 only starts the embedded HTTP MCP server when #[cfg(feature = "mcp")] is set. The Linux/Windows GUI build step runs cargo build --release --target ${{ matrix.target }} with no feature flags, so the shipped dash-evo-tool binary has no MCP server compiled in. Setting MCP_API_KEY on these builds will do nothing, contradicting the changelog entry for #773 which advertises the MCP server. (Note: det-cli is still built with --features headless on line 106, so stdio/HTTP MCP is available via that binary — but the GUI-embedded HTTP server is not.)
💡 Suggested change
- name: Build GUI
run: |
cargo build --release --features mcp --target ${{ matrix.target }}
mv target/${{ matrix.target }}/release/dash-evo-tool${{ matrix.ext }} dash-evo-tool/dash-evo-tool${{ matrix.ext }}
env:
OPENSSL_STATIC: "1"
🔴 blocking: macOS ARM64 GUI also built without the `mcp` feature
.github/workflows/release.yml (lines 225-230)
The macOS ARM64 GUI build at lines 225-230 runs cargo build --release --target aarch64-apple-darwin without any feature flags, so the same omission as the Linux/Windows step applies: the shipped GUI cannot expose the MCP server even when MCP_API_KEY is set. The companion det-cli is built with --features headless at line 234, but the GUI-embedded server is missing.
💡 Suggested change
- name: Build ARM64 architecture
run: |
cargo build --release --features mcp --target aarch64-apple-darwin
mkdir -p build
cp target/aarch64-apple-darwin/release/dash-evo-tool build/dash-evo-tool
chmod +x build/dash-evo-tool
🔴 blocking: x86_64 macOS build uses `cli` instead of `headless`, dropping MCP server modes
.github/workflows/release.yml (lines 541-548)
Unlike the ARM64 macOS job (which builds GUI + det-cli in separate steps with proper features), the x86_64 macOS job builds both binaries together with only --features cli. Per Cargo.toml line 105, headless = ["cli", "mcp"], so cli alone enables the client but excludes the mcp feature. This means: (1) the GUI on x86_64 macOS has no embedded HTTP MCP server (same defect as the other GUI builds), and (2) the det-cli shipped here lacks the Headless subcommand, which is gated on #[cfg(feature = "headless")] at src/bin/det_cli/main.rs:52. The x86_64 macOS artifact is materially less capable than ARM64 macOS and inconsistent with the release notes.
💡 Suggested change
- name: Build x86_64 architecture
run: |
cargo build --release --features headless --target x86_64-apple-darwin
mkdir -p build
cp target/x86_64-apple-darwin/release/dash-evo-tool build/dash-evo-tool
chmod +x build/dash-evo-tool
cp target/x86_64-apple-darwin/release/det-cli build/det-cli
chmod +x build/det-cli
🔴 blocking: Flatpak artifact compiles GUI without `mcp` feature
flatpak/org.dash.DashEvoTool.yml (lines 77-79)
The Flatpak manifest builds with cargo build --release --locked and no feature flags. As with the GitHub Actions release workflow, this excludes the feature-gated MCP module (src/lib.rs:13) and the AppState startup path that launches the HTTP server when MCP_API_KEY is set (src/app.rs:427). The Flatpak release published from this PR will therefore not expose MCP over HTTP, even though the changelog (#773) advertises it.
💡 Suggested change
build-commands:
- cargo build --release --locked --features mcp
- install -Dm755 target/release/dash-evo-tool /app/bin/dash-evo-tool
- install -Dm644 flatpak/org.dash.DashEvoTool.desktop /app/share/applications/org.dash.DashEvoTool.desktop
- install -Dm644 flatpak/org.dash.DashEvoTool.metainfo.xml /app/share/metainfo/org.dash.DashEvoTool.metainfo.xml
- install -Dm644 assets/DET_LOGO.png /app/share/icons/hicolor/512x512/apps/org.dash.DashEvoTool.png
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `.github/workflows/release.yml`:
- [BLOCKING] lines 97-100: GUI binaries built without the `mcp` feature on Linux/Windows
`src/lib.rs:13` gates the entire `mcp` module on `cfg(any(feature = "mcp", feature = "cli"))`, and `src/app.rs:427` only starts the embedded HTTP MCP server when `#[cfg(feature = "mcp")]` is set. The Linux/Windows GUI build step runs `cargo build --release --target ${{ matrix.target }}` with no feature flags, so the shipped `dash-evo-tool` binary has no MCP server compiled in. Setting `MCP_API_KEY` on these builds will do nothing, contradicting the changelog entry for #773 which advertises the MCP server. (Note: `det-cli` is still built with `--features headless` on line 106, so stdio/HTTP MCP is available via that binary — but the GUI-embedded HTTP server is not.)
- [BLOCKING] lines 225-230: macOS ARM64 GUI also built without the `mcp` feature
The macOS ARM64 GUI build at lines 225-230 runs `cargo build --release --target aarch64-apple-darwin` without any feature flags, so the same omission as the Linux/Windows step applies: the shipped GUI cannot expose the MCP server even when `MCP_API_KEY` is set. The companion `det-cli` is built with `--features headless` at line 234, but the GUI-embedded server is missing.
- [BLOCKING] lines 541-548: x86_64 macOS build uses `cli` instead of `headless`, dropping MCP server modes
Unlike the ARM64 macOS job (which builds GUI + det-cli in separate steps with proper features), the x86_64 macOS job builds both binaries together with only `--features cli`. Per `Cargo.toml` line 105, `headless = ["cli", "mcp"]`, so `cli` alone enables the client but excludes the `mcp` feature. This means: (1) the GUI on x86_64 macOS has no embedded HTTP MCP server (same defect as the other GUI builds), and (2) the `det-cli` shipped here lacks the `Headless` subcommand, which is gated on `#[cfg(feature = "headless")]` at `src/bin/det_cli/main.rs:52`. The x86_64 macOS artifact is materially less capable than ARM64 macOS and inconsistent with the release notes.
In `flatpak/org.dash.DashEvoTool.yml`:
- [BLOCKING] lines 77-79: Flatpak artifact compiles GUI without `mcp` feature
The Flatpak manifest builds with `cargo build --release --locked` and no feature flags. As with the GitHub Actions release workflow, this excludes the feature-gated MCP module (`src/lib.rs:13`) and the `AppState` startup path that launches the HTTP server when `MCP_API_KEY` is set (`src/app.rs:427`). The Flatpak release published from this PR will therefore not expose MCP over HTTP, even though the changelog (#773) advertises it.
| - Cache settings reads to avoid 20 queries per second (#420) | ||
| - Optimize x86-64 builds for base x86-64 CPU (#267) | ||
|
|
||
| [1.0.0-dev.1]: https://github.com/dashpay/dash-evo-tool/releases/tag/v1.0.0-dev.1 |
There was a problem hiding this comment.
💬 Nitpick: Use a compare URL instead of a release-tag URL for the version link
Keep a Changelog (which this file's header cites) conventionally uses compare URLs at the bottom — they're more useful to readers and don't 404 between merge and tag-publication. Using a tag URL here means the link will be broken until the post-merge tagging step runs.
💡 Suggested change
| [1.0.0-dev.1]: https://github.com/dashpay/dash-evo-tool/releases/tag/v1.0.0-dev.1 | |
| [1.0.0-dev.1]: https://github.com/dashpay/dash-evo-tool/compare/v0.8.0...v1.0.0-dev.1 |
source: ['claude']
|
|
||
| ## [1.0.0-dev.1] - 2026-04-16 | ||
|
|
There was a problem hiding this comment.
💬 Nitpick: Add an [Unreleased] section to seed the post-release pattern
Keep a Changelog recommends maintaining an ## [Unreleased] section above the latest release to collect changes between releases. Adding it now sets the convention for subsequent contributors and avoids per-PR churn debating where to add new entries.
source: ['claude']
| <!-- Version and date are auto-synced from Cargo.toml by CI (flatpak.yml) --> | ||
| <releases> | ||
| <release version="1.0.0-dev" date="2026-02-17" type="development" /> | ||
| <release version="1.0.0-dev.1" date="2026-04-16" type="development" /> |
There was a problem hiding this comment.
💬 Nitpick: Manual version/date edit duplicates CI auto-sync
The comment on line 46 states that version and date are auto-synced from Cargo.toml by .github/workflows/flatpak.yml (confirmed at lines 43-62 of that workflow, which uses sed to rewrite the version/date and then fails the build if the rewrite did not take effect). The manually edited values are harmless because CI overwrites them, but they invite drift (the date here is the commit day, while CI uses the release publication day). Either leave this file untouched in release-bump PRs or drop the auto-sync step to have a single source of truth.
source: ['claude']
| The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), | ||
| and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). | ||
|
|
||
| ## [1.0.0-dev.1] - 2026-04-16 |
There was a problem hiding this comment.
💬 Nitpick: Release date set to commit day rather than tag day
2026-04-16 matches the commit author date, but per the PR description the tag/release is created post-merge. If this PR sits open before merging, the date here will not match when v1.0.0-dev.1 is actually published. Consider updating the date during the tagging step (and aligning with flatpak.yml, which prefers github.event.release.published_at).
source: ['claude']
3 participants
Summary
1.0.0-dev.1in Cargo.toml, Cargo.lock, and Flatpak metadataDetails
First pre-release toward v1.0.0, covering major features added since v0.8.0:
Post-merge
After merging, tag
v1.0.0-dev.1and create a GitHub Release to trigger CI cross-platform builds.🤖 Co-authored by Claudius the Magnificent AI Agent