Persona edits silently leave linked instance parallelism and ACP command stale #5508

Activity

1. wolfyy970 commented on Aug 10, 2026

   

   wolfyy970

   on Aug 10, 2026

   More actions

   I think this is the same ownership problem being worked on in #5328. Blindly cascading persona values into every linked record would overwrite deliberate instance choices.

   The durable rule should be: the template owns defaults, an agent stores only explicit overrides, and runtime resolution records what the current generation actually applied. The edit flow must also say whether the owner is editing this agent or its template, show which agents the template change affects, and show restart or redeploy required until applied state matches.
2. rsaulo commented on Aug 11, 2026

   

   rsaulo

   on Aug 11, 2026

   Author

   More actions

   Agreed, and thanks for the pointer — I read through #5328 and you are right that this is the same ownership problem. Linking it explicitly: this issue is the runtime-side half of the blocker you have been holding #5328 on. Your durable rule is the right one, so let me add what the persona path specifically breaks under it, because I do not think it is covered by the dialog work yet.

   1. There is no record of what the running generation applied — for these two fields there cannot be one today.

   Your third bullet — runtime resolution records what the current generation actually applied — is exactly what is missing here. BUZZ_ACP_AGENTS is computed from raw record.parallelism at spawn (runtime.rs:677-678) and acp_command is read raw at runtime.rs:476-477, neither through resolve_effective_config. Nothing writes the applied value back, so there is no state to compare the saved value against. "Restart or redeploy required" cannot be surfaced for these two fields until that resolution goes through the effective-config path that model, provider, prompt and persona env already use.

   2. Under your rule, these fields are currently neither a default nor an explicit override.

   The instance's parallelism and acp_command are snapshots seeded at link time, not choices the owner made. If #5328 lands the template/override model and treats every existing instance value as an explicit override, every already-linked agent keeps a phantom override, and template edits go on appearing to do nothing — the same silent divergence, now with a UI that claims field ownership is settled. So this needs a migration call: an instance value that still equals the persona value it was seeded from should resolve as inherit, not as a frozen override.

   3. acp_command is the worst case because there is no way out of it.

   In desktop-v0.5.8 the instance-edit dialog is not reachable for an agent linked to a persona, so a stale acp_command is a phantom override the owner cannot see or correct from any UI path — only by editing the instance record directly. Whatever object-choice UI #5328 settles on, this field needs an escape hatch on day one.

   One smaller overlap worth flagging: the parallelism validation gap in your last review at 8cc6e5a11 (no maximum, nonblank 0/negatives silently reverting) is the same field as this one. If validation lands on the definition form while the value is still resolved raw from the instance record at spawn, a valid definition value and an invalid instance snapshot can still coexist. Validating where the value is resolved, not only where it is typed, would close both.

   Happy to fold this into #5328 as a review comment instead if you would rather keep it in one place — the reproduction and the code references are in the issue body above.
3. wolfyy970 commented on Aug 11, 2026

   

   wolfyy970

   on Aug 11, 2026

   More actions

   Keep this issue open. It gives #5328 a concrete runtime acceptance test, and I would not bury it in that PR.

   One correction after checking current main: local processes already stamp acp_command and effective parallelism in SpawnConfigSnapshot, so the applied-state seam exists. The missing piece is desired resolution. Parallelism still comes from the copied record, so a template change produces no prospective diff. acp_command is different: AgentDefinition has no such field. The definition owns the agent runtime, while buzz-acp remains instance and target launch plumbing.

   For migration, equality can safely become inherit. A different legacy value is ambiguous, so I would preserve it as a legacy override and ask the owner rather than guess. I will use this issue as the runtime dependency for #5328.
4. uevuleocha commented on Aug 21, 2026

   

   uevuleocha

   on Aug 21, 2026

   More actions

   Adding a Windows confirmation and one data point I have not seen in the thread, which bears on @wolfyy970's last point about desired resolution.

   The desired value is stored — it just is not the field the spawn path reads.

   On a persona-linked setup where the persona parallelism was changed from 10 to 5, the saved state is:

   • each definition record: parallelism: 10, definition_parallelism: 5
   • each instance record: parallelism: 10, definition_parallelism unset

   So the edit is not discarded. It lands in definition_parallelism, and every consumer that matters ignores it. agent_snapshot.rs:214 resolves record.definition_parallelism.or(Some(record.parallelism)), so the exported AgentDefinition reflects the change and a newly minted instance would inherit 5 — while runtime.rs:680 computes BUZZ_ACP_AGENTS from raw record.parallelism and every existing instance keeps 10 indefinitely.

   If that reading is right, a prospective diff for parallelism may not need a new field: definition_parallelism versus the instance's parallelism is already a desired-versus-applied pair for exactly the fields under discussion. Worth confirming against main before it is designed around — I am reading a f88cda9 clone.

   Windows, v0.5.17. Reproduces nine minor versions after the report, on a different platform.

   A restart that isolates the propagation path. After changing parallelism on all four agents and restarting one, its startup line reads:

   buzz-acp starting: ... idle_timeout=900s max_turn=7200s agents=10 ... context_limit=20 max_turns_per_session=0 ...
   

   context_limit=20 in the same line is a change made in the same dialog, in the same session, that did propagate. Same restart, same record, same form — one setting arrives and the other does not. That may be a useful control when testing a fix.

   Sibling report. #5400 describes the same field from the instance-edit side and concludes the value is "being dropped from the record." If the definition_parallelism behaviour above is what is happening there too, it is not dropped but misfiled, which would make these two reports the same root cause seen from either end of the link.
5. cristiansotogarciaxatech commented on Oct 10, 2026

   

   cristiansotogarciaxatech

   on Oct 10, 2026

   More actions

   Same bug here on Windows 11 (Buzz Desktop, 2026-10-10), on more than one agent.

   1. Edit agent > Advanced > Parallelism changed from blank (app default 10) to 3, Save changes.
   2. Restarted the agent, then a full Buzz Desktop restart.
   3. buzz-acp startup line still reads agents=10.

   In %APPDATA%\xyz.block.buzz.app\agents\managed-agents.json after saving:

   • persona/definition row (persona_id set, no pubkey): "definition_parallelism": 3, "parallelism": 10
   • linked instance row (pubkey set): "parallelism": 10

   The runtime launches from the instance row, so the saved value never takes effect, and nothing in the dialog shows the divergence. Setting parallelism on the instance row by hand and restarting the agent is the workaround. #5400 looks like the same root cause.