Show pending checkpoint processing in status - #2052
Conversation
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| @@ -6544,6 +6544,7 @@ impl ActorDaemonCoordinator { | |||
| last_error: status | |||
| .last_error | |||
| .or_else(|| self.latest_side_effect_error(&family_key).ok().flatten()), | |||
There was a problem hiding this comment.
🟡 Status warns about pending work even when the pending work belongs to a different repository
The pending-work count reported for a specific repository is actually the background service's global count of unfinished checkpoints across every repository (self.outstanding_checkpoint_state().0 at src/daemon.rs:6546), so a repository with nothing in flight can still be reported as busy.
Impact: Users can see a "processing still in progress, status may be incomplete" warning in a repository that has no pending work, simply because another repository on the machine is being processed.
Global ingress quota vs. family-scoped response field
FamilyStatus is a per-family (per-repo) response (src/daemon/control_api.rs:139-146), but outstanding_checkpoint_state() returns self.checkpoint_ingress_quota.outstanding() (src/daemon.rs:6788-6790), which is a single process-wide counter incremented in the checkpoint receive loop (src/daemon.rs:7404) and released on reservation drop (src/daemon.rs:225). It has no family/repo dimension. The production daemon is shared system-wide, so git-ai status in repo A reports checkpoint_processing_pending = true while repo B's checkpoints are still queued (src/commands/status.rs:242-249).
A family-scoped count would need to be derived from per-family sequencer state (e.g. counting FamilySequencerEntry::Checkpoint entries for the resolved family) rather than the global quota.
Prompt for agents
status_for_family in src/daemon.rs returns pending_checkpoints from self.outstanding_checkpoint_state(), which delegates to the process-wide checkpoint_ingress_quota (src/daemon.rs:6788). Because the daemon is shared across all repositories, a StatusFamily response for repo A reports checkpoints that are queued for repo B, causing git-ai status (src/commands/status.rs) to print a spurious 'processing still in progress' warning. Consider deriving a family-scoped pending count, e.g. by counting outstanding FamilySequencerEntry::Checkpoint entries (and in-flight checkpoint side effects) for the resolved family key, and use that for the family status response.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
|
||
| fn run_status(json: bool, diff_only: bool) -> Result<(), GitAiError> { | ||
| let repo = find_repository(&[])?; | ||
| let checkpoint_processing_pending = checkpoint_processing_pending(&repo); |
There was a problem hiding this comment.
🟡 Pending-work warning can be missed for work that arrives while status is being computed
Whether background processing is still pending is checked (checkpoint_processing_pending(&repo) at src/commands/status.rs:61) before the attribution data is read rather than after, so work that starts during the read is displayed without any warning.
Impact: Users can occasionally see incomplete attribution numbers with no indication that more processing was still happening.
Ordering of the pending probe relative to the working-log read
The probe happens first at src/commands/status.rs:61, while the working log and checkpoints are read afterwards at src/commands/status.rs:70-72 and the diff stats later still. If a checkpoint is accepted by the daemon between the probe and the reads, the printed status reflects a partially-processed state but checkpoint_processing_pending is false. Probing after all reads closes that window: the worst case then becomes a harmless false-positive warning (work that finished during the read) instead of a silently incomplete report.
Prompt for agents
In run_status (src/commands/status.rs), checkpoint_processing_pending(&repo) is evaluated before the working log, checkpoints and diff stats are read. A checkpoint admitted by the daemon during those reads yields incomplete output with no warning. Move the pending probe so it runs after the data used for the output has been gathered (both in the early-return empty branch and in the main path), so the flag conservatively reports pending work that overlapped the read.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
What changed
git-ai statusoutput while checkpoint processing is pendingcheckpoint_processing_pendingto JSON status outputfalseresultWhy
Async checkpoint receipts can return before the working log is updated, so
git-ai statusmay otherwise display incomplete information with no indication that more attribution is still being processed.Validation
task fmttask linttask test