[Bug]: Changes row count shows immediately on new Task with no changes, and doesn't update after actual changes

[khuongdo]

Summary

After initializing a new Task, the "changes" row count displays a non-zero number immediately — even though no changes have been made yet. Conversely, after actual file changes occur, the count does not update to reflect them. This is intermittent, not always reproducible.

Affected area

Web UI

Kandev version

v0.50.0

Install mode

Docker Compose

Environment

• OS: Windows 11 + WSL2
• Architecture: amd64
• Browser: (latest Chromium-based)

Kandev configuration

• N/A (default config)

Task/session context

N/A — reproducible on any newly created Task

Steps to reproduce

1. Start Kandev
2. Create a new Task
3. Observe the "changes" row in the Task panel immediately shows a non-zero count even though no changes have been made
4. Have the agent make file changes
5. Observe the changes count does not update to reflect the actual number of changed files

Reproducibility

Sometimes

Clean-state check

Not tried

Expected behavior

The changes row should show 0 (or be empty) on a newly created Task with no changes. After agent makes file changes, the count should update to reflect the real number of changed files.

Actual behavior

Changes count appears immediately on Task creation (before any changes). After actual changes are made by the agent, the count stays stale and does not reflect the real state.

Logs and artifacts

No logs observed.

Last known good version

unknown

Extra context

Intermittent — not always reproducible. Likely a race condition or stale state in the changes counter UI binding on Task initialization.

Before submitting

• I can reproduce this using the steps above.
• I removed secrets, tokens, private repository URLs, private prompts, and customer data.
• I searched existing issues and did not find a duplicate.

[jcfs]

Thanks for the detailed report! I spent a while trying to reproduce this on a default single-repo setup and couldn't trigger it — the count stayed at 0 for me through new task creation, and updated correctly once the agent made changes.

That said, while digging through the code I did find a related race in how the changes count is sourced: it reads the single byEnvironmentId slot, which is last-write-wins across repos. In a multi-repo workspace that makes the count flicker as sibling repos overwrite each other, and it can leave stale values lingering. It's plausible this is what you hit (especially given the "intermittent" + "doesn't update after actual changes" pattern), but I can't say for sure without reproducing your exact setup.

I've opened #986 with a fix that aggregates the count across all repos. If you can pull that branch (feature/implement-bug-change-aa0) and see whether the bug still reproduces on your end, that would be a huge help in confirming whether this is the right fix or if there's still another root cause to chase.

[khuongdo]

@jcfs
Thank you for your help.
I tried to cleanup cache, but the issue is still persist.
And you are right, I have 2 repos in the workspace.
btw, there is warning log on the browser console

[review] cumulative diff entry missing `path` field; skipping 
{mapKey: `XXX`, repoName: undefined }

Hope it helps.

[jcfs]

Good — the 2-repo workspace confirmation lines up with my theory, so we're on the right track at least on the cause front.

One thing I want to double-check before digging further: when you say "the issue still persists", did you mean after pulling the feature/implement-bug-change-aa0 branch and rebuilding, or after clearing browser cache on the current released version? The fix is server-side / bundled JS, so a cache clear alone wouldn't pick it up — it needs a rebuild from that branch. If you haven't tried the branch yet, that's the next thing I'd want to confirm before chasing other causes.

The console warning you spotted is interesting but coming from a different code path (the review dialog's cumulative-diff handling, not the Changes-tab counter). Worth a separate issue eventually, but probably unrelated to the count problem — happy to look into it once we've nailed down the main one.

[carlosflorencio]

We did several changes to the changes panel in the last releases, regarding WS subscription.

This issue still happens?

[khuongdo-nicosys]

I confirm that the issue is fixed in version v.60.0
Thanks.