fix: update reports in place - #53
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dd4a1bebe3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3ae8c2bdb3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 628eac5867
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return ( | ||
| !previous || | ||
| previous.body !== entry.body || | ||
| previous.severity !== entry.severity || |
There was a problem hiding this comment.
When a pull request changes only the severity of an entry that already carries its issue: link—the normal state after reconciliation—this predicate now selects it, but partition(changed) immediately classifies it as linked and excludes it from filing.file. The issue's marker therefore retains the old severity, so recreating the entry after a reopen restores stale data. The final code's new severity predicate combined with the unchanged linked-entry partition is fresh evidence that the earlier severity fix still misses this lifecycle state.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 70998151a6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (issue.body?.includes(marker)) existing = preferred(existing, issue) | ||
| if (existing) return reindex(existing, title) | ||
|
|
||
| existing = (await commentOccurrences()).markers.get(marker) |
There was a problem hiding this comment.
When migrating a v1 report, the new report marker is absent but its compatibility occurrence is usually already in the issue body. Because the loop calls commentOccurrences() for the missing report marker before checking the occurrence marker, every such migration first lists all fallback issues and may scan up to 5,000 repository comments, even though the next iteration can resolve the issue locally. Check all issue-body markers (and the mirror identity) before starting the repository-wide comment scan to avoid consuming substantial API quota on established repositories.
Useful? React with 👍 / 👎.
| 'frog': patch | ||
| --- | ||
|
|
||
| Updated existing reports in place and reserved recurrence comments for new friction entries. |
There was a problem hiding this comment.
When an Action-only or CLI user edits a normally filed entry, the entry already contains the issue: link written by its first publish, but src/cli/commands/publish.ts still filters work to entries.value.filter((entry) => !entry.issue) and returns immediately when none are pending. Consequently the new report/revision update path is never reached for ordinary linked entries in that automation mode, so title, body, and severity edits leave the issue stale despite this changeset's update-in-place claim. Process established links through a validated update path, as the App flow now does.
Useful? React with 👍 / 👎.
| if (location.status === 'created') { | ||
| await client.issues.update({ | ||
| ...split(repo), | ||
| body: preserveBodySuffix(body, location.body), |
There was a problem hiding this comment.
When contributor B edits a report originally filed by contributor A, the App passes B and the current PR as provenance, and this replacement uses that newly rendered body—including its new footer—instead of retaining the existing attribution. The issue therefore changes from “Logged by @A … via PR A” to B/PR B, even though the footer is documented in pullRequest.test.ts as the only trace of who hit the friction and the CLI provenance path deliberately reads the file-add commit so later edits do not reattribute it. Preserve the existing report provenance while replacing only its editable content and markers.
Useful? React with 👍 / 👎.
1 participant
Uses stable report identities and content revisions to update existing issues or comments in place. New entry IDs alone create recurrence comments, while legacy occurrence markers migrate without duplicates.