Repository navigation
chore(release): agentflare v1.5.0 - #274
Conversation
Manual version bump — release-plz's release-pr step returned an empty prs:[] despite 43 commits (several feat:) since v1.4.0, and root-causing that is a separate task. Bumping directly so this can be tagged and dogfooded.
📝 WalkthroughWalkthroughThe package version was bumped to 1.5.0, and ChangesRelease metadata
Estimated code review effort: 1 (Trivial) | ~3 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Cargo.toml`:
- Line 7: Update the release metadata alongside Cargo.toml’s version bump:
change all 1.4.0 references in bucket/agentflare.json, including the Windows
download URL, to 1.5.0, and update the displayed version in
site/public/index.html to v1.5.0.
In `@CHANGELOG.md`:
- Line 10: Update the 1.5.0 changelog entry date in the release heading to the
actual current release date, July 19, 2026, unless the release is intentionally
scheduled for July 20.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: e781787e-cc70-483e-ab7a-61cd27984372
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (2)
CHANGELOG.mdCargo.toml
| [package] | ||
| name = "agentflare" | ||
| version = "1.4.0" | ||
| version = "1.5.0" |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Repo root: '; pwd
printf '\nTracked files of interest:\n'
git ls-files | rg '^(Cargo\.toml|bucket/agentflare\.json|site/public/index\.html)$' || true
printf '\nCargo.toml excerpt:\n'
sed -n '1,30p' Cargo.toml
printf '\nbucket/agentflare.json excerpt:\n'
sed -n '1,120p' bucket/agentflare.json
printf '\nsite/public/index.html excerpt:\n'
sed -n '1,160p' site/public/index.htmlRepository: getappz/agentflare
Length of output: 12299
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Searching for version strings and download URL references:\n'
rg -n '"1\.4\.0"|"1\.5\.0"|v1\.4\.0|v1\.5\.0|windows|download' Cargo.toml bucket/agentflare.json site/public/index.html . || trueRepository: getappz/agentflare
Length of output: 19638
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
import json, pathlib, re
paths = [pathlib.Path('bucket/agentflare.json'), pathlib.Path('site/public/index.html')]
for path in paths:
print(f'\n## {path}')
if not path.exists():
print('missing')
continue
text = path.read_text()
if path.suffix == '.json':
try:
data = json.loads(text)
except Exception as e:
print('json parse error:', e)
continue
# print version-ish keys and URLs
def walk(obj, prefix=''):
if isinstance(obj, dict):
for k, v in obj.items():
p = f'{prefix}.{k}' if prefix else k
if k.lower() in {'version', 'url', 'windowsurl', 'windows_url', 'download', 'downloadurl'} or isinstance(v, (str, int, float)):
if isinstance(v, str) and ('1.4.0' in v or '1.5.0' in v or 'windows' in v.lower() or 'download' in v.lower()):
print(p, '=', v)
walk(v, p)
elif isinstance(obj, list):
for i, v in enumerate(obj):
walk(v, f'{prefix}[{i}]')
walk(data)
else:
for m in re.finditer(r'1\.[45]\.0|v1\.[45]\.0|windows|download', text, re.I):
start = max(0, m.start()-80)
end = min(len(text), m.end()+120)
print(text[start:end].replace('\n', ' '))
print('---')
PYRepository: getappz/agentflare
Length of output: 877
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show surrounding lines for any matched references in the claimed files.
for f in Cargo.toml bucket/agentflare.json site/public/index.html; do
[ -f "$f" ] || continue
echo "==== $f ===="
rg -n -C 2 '1\.4\.0|1\.5\.0|v1\.4\.0|v1\.5\.0|windows|download' "$f" || true
doneRepository: getappz/agentflare
Length of output: 2573
Keep release metadata in sync with the crate version. bucket/agentflare.json still pins 1.4.0 (including the Windows download URL), and site/public/index.html still shows v1.4.0, so this bump would leave the installer and badge stale. Update those files together with Cargo.toml.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Cargo.toml` at line 7, Update the release metadata alongside Cargo.toml’s
version bump: change all 1.4.0 references in bucket/agentflare.json, including
the Windows download URL, to 1.5.0, and update the displayed version in
site/public/index.html to v1.5.0.
|
|
||
| ## [Unreleased] | ||
|
|
||
| ## [1.5.0](https://github.com/getappz/agentflare/compare/v1.4.0...v1.5.0) - 2026-07-20 |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Use the actual release date.
This section is dated July 20, 2026, but the current date is July 19, 2026. Unless the release is intentionally scheduled for July 20, use the actual release date to avoid future-dated release history.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@CHANGELOG.md` at line 10, Update the 1.5.0 changelog entry date in the
release heading to the actual current release date, July 19, 2026, unless the
release is intentionally scheduled for July 20.
…s-project dispatch retry loop) (#759) * fix(shim): own re-entry marker stops the lean-ctx <-> bash fork-bomb Neither agentflare dispatcher -- the `~/.bashenv` `_af_dispatch` function nor the compiled PATH shim -- had a re-entry guard of its own. Both only honored lean-ctx's user-facing opt-outs (LEAN_CTX_DISABLED/NO_HOOK), and lean-ctx deliberately clears its own LEAN_CTX_WRAPPED/LEAN_CTX_ACTIVE markers on its delegate-to-shell path, so a shell that lean-ctx spawns could re-enter a dispatcher unmarked, spawn a fresh unwrapped `lean-ctx -c`, which spawned another shell, without bound. Observed live on 2026-09-16 as ~8,000 orphaned bash.exe/lean-ctx.exe processes and system memory exhaustion (image-qc vents #274 and #278), and reproduced on 2026-09-17. Both dispatchers now stamp AGENTFLARE_SHIM_ACTIVE=1 on the lean-ctx child they spawn and treat it (plus LEAN_CTX_WRAPPED, one hop earlier) as a kill switch: anything inside a command tree an agentflare dispatcher already handed to lean-ctx execs the real tool. lean-ctx never touches that variable, so it survives every lean-ctx spawn path and every shell lean-ctx starts. The regression test drives the generated .bashenv block with a fake lean-ctx that re-runs its command in a fresh bash under the same BASH_ENV -- the exact pathological lap -- and gives up after five laps so a regression fails instead of hanging. Against the previously installed block that harness measures six laps (exit 99); with this change, one. Agentflare-Agent: claude-code_2-1-274_agent Agentflare-Branch: fix/process-storms Agentflare-Session: db2a8bd7-2d5e-425b-935e-bf58bc998a87 * fix(supervisor): record dispatch bookkeeping by canonical id so the failure ceiling can trip for every project The discovery tick walks every registered `project_dirs` folder, but its `AgentflareMcp` is linked to only the project this daemon process was started in. `dispatch_item`, `skip_item` and `ask_item` did their label swap and comment through the `ItemRequest`/`CommentRequest` MCP entry points, which resolve ids via `resolve_item_id` and reject any item outside that one linked project -- and every call was `let _ =`. The daemon started by the watchdog scheduled task runs from C:\Windows\System32, which matches no real project at all, so since 2026-08-31 not one `## supervisor — dispatched` marker landed on any item in any project. `dispatch_failure_ceiling` counts dispatch cycles by exactly that marker, so it counted zero, `handle_terminal_job_failure` put `ready-for-work` straight back after every terminal failure, and a deterministically failing item was re-dispatched every SUPERVISOR_DISCOVERY_INTERVAL without bound: image-qc item #273 ran 1,367 identical failing jobs, one every 12 seconds, across 31 hours (2026-09-16/17). A skipped item likewise never lost `ready-for-work` and was re-skipped, with a fresh comment, every tick. Do the swap and the comment directly against the backend by the item's own canonical ids (the same way `handle_terminal_job_failure` already does), and log a failure instead of swallowing it -- a swap that silently doesn't land is precisely what re-arms the loop (item #221). The regression test seeds a ready item in a second project reachable only through `project_dirs` and asserts the tick strips `ready-for-work`, adds `dispatched`, and posts the marker; against the previous code it fails on the first assertion. The trigger for #273's failures (a stale worktree registration that `remove_stale_registration_for` only clears when its HEAD names the same branch, while git refuses by path) is tracked separately as item #588. Agentflare-Agent: claude-code_2-1-274_agent Agentflare-Branch: fix/process-storms Agentflare-Session: db2a8bd7-2d5e-425b-935e-bf58bc998a87 * fix(supervisor): address CodeRabbit review findings on record_supervisor_action/dispatch_item Two of the three findings from PR #759's automated review: 1. record_supervisor_action's three backend writes (remove_label, add_label, comment::create) ran as separate auto-committed statements, not a transaction -- with_backend_db only locks and opens the connection, it does not start one. A failure partway through (e.g. add_label after remove_label already committed) left the exact half-applied state this PR's other fix exists to prevent: an item with neither label and no dispatch marker, invisible to both the discovery query and the failure ceiling. Wrapped in conn.unchecked_transaction(), the pattern this codebase already uses elsewhere (label.rs, project.rs, item/claim.rs, item/crud.rs). 2. dispatch_item resolved DISPATCHED_LABEL only when swapping labels, after the job was already enqueued. run_discovery_tick only requires READY_LABEL to exist before batching a project, so a project that never got DISPATCHED_LABEL seeded would enqueue a real job, remove ready-for-work, and leave the item wearing neither label. Resolved before enqueue_work_job now; returns NotDispatched (no job, no label change) when the label doesn't exist, so a human fixing the missing label sees the item again on the very next tick instead of a silently orphaned item. The third finding (a rarer failure mode: the enqueue and the bookkeeping are two different SQLite databases with no shared transaction, so the bookkeeping write can still fail outright after the job is already enqueued) is real but tagged "heavy lift" by the review itself -- tracked separately as agentflare item #591 rather than folded into this fix. Regression tests for both: dispatch_item_declines_when_the_project_has_no_dispatched_label asserts no job is enqueued and ready-for-work stays on; the existing cross-project test continues to cover the transactional write path. Agentflare-Agent: claude-code_2-1-274_agent Agentflare-Branch: fix/process-storms Agentflare-Session: db2a8bd7-2d5e-425b-935e-bf58bc998a87
Summary
Manual version bump (1.4.0 → 1.5.0) covering the 43 commits merged since the last release, including #271 (daemon lifecycle + upgrade-cache), flare-proxy, @mentions,
agentflare work, vent, the memory hybrid-recall migration, and agentflare-store.release-plz'srelease-prstep returned{"prs":[]}for this range despite severalfeat:commits sincev1.4.0— worth investigating separately, but not blocking this release.Test plan
cargo check— 0 errorsCargo.lockregenerated, version confirmed at 1.5.0Summary by CodeRabbit