Preserve issue creationDate during migration via synthetic SCM change…#125
Conversation
…sets Instead of creating a single stub changeset per file with Date.now(), changeset extraction now uses issue creation dates to build per-line date mappings. The Compute Engine uses SCM blame dates to set issue creationDate, so by encoding the original dates into synthetic changesets, migrated issues retain their original creation timestamps. Applied across all pipeline versions (sq-9.9, sq-10.0, sq-10.4, sq-2025) for both main branch and branch extraction paths. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
SummaryThis PR enhances issue migration to preserve original creation dates by encoding them into synthetic SCM changesets. What changed:
Why it matters: Scope: What reviewers should knowKey files to review:
Non-obvious details:
What to watch for:
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit e3bbbd4. Configure here.
| restore: (d) => { ctx.duplications = d; } }, | ||
| { name: 'extract:changesets', label: 'Step 8: Extracting changesets', | ||
| fn: async () => { ctx.changesets = await extractChangesets(extractor.client, ctx.sourceFilesList, ctx.components); return ctx.changesets; }, | ||
| fn: async () => { ctx.changesets = await extractChangesets(extractor.client, ctx.sourceFilesList, ctx.components, ctx.issues); return ctx.changesets; }, |
There was a problem hiding this comment.
Hotspot issues excluded from changeset date mapping in checkpoint paths
Medium Severity
In all checkpoint-based extraction paths, ctx.issues is passed to extractChangesets before hotspot issues have been merged in. Hotspots are extracted into ctx.hotspotIssues and only merged into ctx.issues after all phases complete (e.g., in extract-all-with-checkpoints.js). This means hotspot creation dates are silently excluded from the synthetic changeset date mappings. Non-checkpoint paths correctly merge hotspots before calling extractChangesets, creating an inconsistency. This affects all four pipeline versions (sq-9.9, sq-10.0, sq-10.4, sq-2025) for both main and branch extraction.
Additional Locations (2)
Reviewed by Cursor Bugbot for commit e3bbbd4. Configure here.
![sonar-review-alpha[bot]](https://avatars.githubusercontent.com/in/3025063?s=60&v=4){kind=small}
| return changesets; | ||
| } | ||
|
|
||
| function buildChangeset(lineCount, fileIssues, fallbackTimestamp) { |
There was a problem hiding this comment.
Logic duplication: The buildChangeset function here is nearly identical to:
src/pipelines/sq-10.0/sonarqube/extractors/changesets/helpers/build-stub-changeset.js(buildStubChangeset)src/pipelines/sq-10.4/sonarqube/extractors/changesets/helpers/extract-changesets.js(buildChangeset)src/pipelines/sq-2025/sonarqube/extractors/changesets/helpers/create-stub-changeset.js(createStubChangeset)
The same algorithm (line→date map, dedup, index assignment, bounds check) is copy-pasted four times with only cosmetic naming differences. This logic is not version-specific — it's pure date-encoding math with no SQ API coupling.
Extract it to src/shared/utils/build-issue-changesets.js and import it in each pipeline. A future change (e.g. switching from earliest to latest date, or adding textRange fallback for issues without a line) currently requires four coordinated edits in non-obvious locations.
- Mark as noise
|
Hi @okorach I managed to achieve this on my other branch however let me try your fix applied here on your branch |
|
will test it on your branch first |
|
the algorithm that claude applied on my current feature branch is a bit buggy (still loads 23 other issues into a single day) |
3 participants
…sets
Instead of creating a single stub changeset per file with Date.now(), changeset extraction now uses issue creation dates to build per-line date mappings. The Compute Engine uses SCM blame dates to set issue creationDate, so by encoding the original dates into synthetic changesets, migrated issues retain their original creation timestamps.
Applied across all pipeline versions (sq-9.9, sq-10.0, sq-10.4, sq-2025) for both main branch and branch extraction paths.
Note
Medium Risk
Changes the generated SCM changeset data used during migration so issue
creationDateis derived from per-line synthetic blame dates; incorrect mappings could shift timestamps on migrated issues. Scope spans multiple pipeline versions and both main/branch extraction paths.Overview
Updates changeset extraction across
sq-9.9,sq-10.0,sq-10.4, andsq-2025to derive synthetic SCM blame dates from issuecreationDateinstead of using a singleDate.now()stub per file.extractChangesetsnow accepts anissueslist, groups issues by file/component, and builds per-linechangesetIndexByLinemappings (with a fallback changeset for lines without issues) so migrated issues retain their original creation timestamps.Reviewed by Cursor Bugbot for commit e3bbbd4. Bugbot is set up for automated code reviews on this repo. Configure here.