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
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 35/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- Active
- Stack technique
- git, javascript, typescript
- Domaine
- cli, observability, tooling
Piste de recherche
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.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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 |
- Langage dominant
- TypeScript
- Étoiles
- 481
- Forks
- 45
- Merge moyen
- 18 h 31 min
- PR mergées (30 j)
- 108
Préparer son environnement
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de ai-driven-dev/framework
-
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
ai-driven-dev/framework#940 ·
Les mainteneurs répondent en général sous 1 jour
-
refactor(aidd-orchestrator): the check zone says when to stop, and reviews its axes in one roundOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
ai-driven-dev/framework#887 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
ai-driven-dev/framework#873 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
ai-driven-dev/framework#625 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
ai-driven-dev/framework#467 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de ai-driven-dev/framework
Issues similaires
-
needs:triage
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
Les mainteneurs répondent en général sous 1 jour
-
ai-discovered
Difficulté 2/5 1-3 heures Accessibilité débutants 83/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
jessepollak/home#1627 ·
Les mainteneurs répondent en général sous 1 jour
-
agent-canvas bug llm priority:low ready-for-dev
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
OpenHands/OpenHands#17806 · 3 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
radius-project/ai-extensions#923 ·
Les mainteneurs répondent en général sous 1 jour