Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

bug(doctor): inert foreign sync targets remain error-tier despite no-action guidance

Open
  • Is something wrong?
#1,864 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
62/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
cli

Research direction

Start in internal/diagnostic/checks.go, where SyncTargetClosedSpaceCheck.Run assigns SeverityError to every foreign state row, and compare it with safeNextStepForForeignSyncTarget, which already treats zero-pending rows as inert. Then read the test "inert foreign row with zero pending mutations keeps the no-action guidance" in checks_closed_space_test.go. Done means a foreign row with zero unacked mutations reports at warning tier, rows with pending mutations stay at error, and the tests cover both cases.

Written by the indexing model from the issue text.

Description

status:needs-review type:bug
📝 Bug Description

An inert foreign sync-state row keeps Doctor in error even when unacked_mutations = 0 and its own guidance says "no action is required" and "no data is at risk". This diagnostic-severity follow-up is split from #1188, not a request to implement cloud-inbox routing.

Earlier trackers #1158 and #1199 are closed. Current main already exposes a local foreign-target repair, so this report does not repeat the historical claim that no repair exists.

🔄 Steps to Reproduce

Reported released-build occurrence (not newly executed by the triage author):

  1. On Engram 3.4.0, retain an unrelated legacy cloud:general state row with lifecycle idle and zero unacknowledged mutations.
  2. Configure Cloud and fully synchronize the explicitly enrolled active project.
  3. Run engram doctor --project <project>.
  4. Observe sync_target_closed_space / foreign_sync_target as an error despite the inert row.

Original evidence: https://github.com/Gentleman-Programming/engram/issues/1188#issuecomment-6158458927

Current source independently pins this behavior: the test case "inert foreign row with zero pending mutations keeps the no-action guidance" seeds an inert foreign row and expects StatusError. This test was inspected, not run during triage.

✅ Expected Behavior

Retain visibility of inert foreign-target drift without error-tier grading when the diagnostic itself establishes no pending mutations and no action required. Warning-tier grading should not require inbox routing or a Cloud backend.

Do not blanket-downgrade targets with pending mutations or other actionable evidence. Preserve local observations, journal history, enrollment and delivery behavior.

❌ Actual Behavior

SyncTargetClosedSpaceCheck.Run assigns SeverityError to every foreign state row; safeNextStepForForeignSyncTarget simultaneously classifies zero-pending rows as inert/no-risk/no-action-required.

Operating System

Not specified in the original 3.4.0 occurrence; source-level finding is platform-independent.

Engram Version

3.4.0 in the linked user report. Source inspected at main commit 11f8f1a58eff8e238148967b32cdc413bd54c90d.

Agent / Client

Other. The original occurrence does not identify a client; the observed interface is Doctor CLI.

📋 Relevant Logs
status: error
checks: 9 ok, 1 error
check_id: sync_target_closed_space
reason_code: foreign_sync_target
target_key: cloud:general
lifecycle: idle
unacked_mutations: 0

Quoted from the linked report, not generated by this triage.

💡 Additional Context

Pinned source:

Out of scope: aliases, two-stage derivation, inbox routing/claim/drop, migration policy, enrolled delivery-lane changes, payload-directory backfill (#1424 / #1443), and speculative data-loss findings. Keep #1188 as the routing feature tracker.

Dominant language
Go
Stars
7.1k
Forks
729
Avg merge
10h 43m
Merged PRs (30d)
332

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Gentleman-Programming/engram

All issues in Gentleman-Programming/engram

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.