fix(aidd-telemetry): a session run in a git worktree is missing from every report outside that worktree, and lost when the worktree is removed
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- git, javascript, typescript
- Bereich
- cli, observability, tooling
Rechercherichtung
Start by reading cli/src/kernel/paths.ts, cli/src/kernel/reading/repository-root.ts, and plugins/aidd-telemetry/hooks/lib/repo.cjs, then review the related issues cited in the proposal. Trace how reports read journals through read-local-cost-use-case.ts and report-cost-use-case.ts. Done means the QA steps pass: reports from any checkout include every worktree, and a removed worktree's session remains visible.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Description
A session run in a git linked worktree is missing from aidd telemetry report run anywhere else, and is lost for good once the worktree is removed.
The hook writes the run journal under the worktree's own aidd_docs/runs/ (git rev-parse --show-toplevel). The CLI reads only the journal of the checkout it runs in, and the sink is filled only from that journal. aidd telemetry on git-ignores aidd_docs/runs/, so git worktree remove deletes the journal with the worktree.
Affected file(s)
cli/src/kernel/paths.ts(resolvedRunsDir)cli/src/kernel/reading/repository-root.ts(repositoryRootAbovestops at the worktree's.gitfile)plugins/aidd-telemetry/hooks/lib/repo.cjs(journal anchored at--show-toplevel)
Expected behaviour
A session run in any worktree of a repository appears in a report run from any checkout of that repository, and still appears after that worktree is removed.
Observed behaviour
One repository, three active worktrees, one Claude Code session each:
| Session | session_start in its worktree journal |
Records in the sink |
|---|---|---|
| A | yes, with worktree_id |
0 |
| B | yes, with worktree_id |
695 (a report was run from B) |
| C | yes, with worktree_id |
0 |
A report from the main checkout sees none of them. Removing the worktree of A or C now leaves no journal to recover their cost from; the transcripts remain but nothing names them.
Proposed solution
- Decide where a worktree's journal lives, or how a report gathers every worktree's journal, and write the decision down. #693 raised this choice; #706 closed it by delivering the
worktree_idfield (#695), and the per-worktree default was kept without a recorded decision. - Whatever is chosen, a journal must outlive
git worktree remove. - A report run from any checkout of a repository counts the sessions of all its worktrees, still told apart by
worktree_id.
Context / Technical constraints
- #693 assumed "sessions from worktree B still contribute their tokens, the sink pools everything, they read as unattributed". That no longer holds: the sink is filled only through the current checkout's journal (
read-local-cost-use-case.ts,report-cost-use-case.tscatch-up), so those sessions are absent, not unattributed. - Committing journals is not an option:
aidd telemetry ongit-ignores them on purpose (telemetry-on-use-case.ts). - Agent runners (Orca, Claude Code under
.claude/worktrees/) give each agent its own worktree, so this is the common case, not an edge case.
Environment
| AI tool | Claude Code 2.1.283 |
| aidd-cli version | 5.4.0 |
| OS | Windows 11 Pro (10.0.26100) |
| node | 24.12.0 |
| aidd-telemetry | 0.2.0 |
QA
- In a repository with telemetry on, create two worktrees and run one session in each.
- From the main checkout, run
aidd telemetry report: both sessions appear, told apart by worktree. git worktree removeone worktree, run the report again: its session still appears.
Relations
| Field | Value |
|---|---|
| parent | #631 |
| related | #693, #695, #657, #707 |
- Vorherrschende Sprache
- TypeScript
- Sterne
- 481
- Forks
- 45
- Ø Merge
- 18 Std. 31 Min.
- Gemergte PRs (30 T.)
- 108
Entwicklungsumgebung
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus ai-driven-dev/framework
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
ai-driven-dev/framework#940 ·
Maintainer antworten meist innerhalb von 1 Tag
-
refactor(aidd-orchestrator): the check zone says when to stop, and reviews its axes in one roundOffen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
ai-driven-dev/framework#887 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
ai-driven-dev/framework#873 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
ai-driven-dev/framework#625 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
ai-driven-dev/framework#467 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in ai-driven-dev/framework
Ähnliche Issues
-
refactor
Schwierigkeit 2/5 Ein halber Tag Anfängerfreundlichkeit 84/100
Maintainer antworten meist innerhalb von 5 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
OHDSI/Data2Evidence#3450 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
e2e-failure ready-to-code
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 90/100
redhat-developer/rhdh-plugin-export-overlays#4011 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
automation missing-model model-sync provider:ofox
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
anomalyco/models.dev#8421 ·
Maintainer antworten meist innerhalb von 1 Tag
-
SlackAdapter and TelegramAdapter are not assignable to Adapter under exactOptionalPropertyTypesOffen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
Maintainer antworten meist innerhalb von 1 Tag