fix(tempo): paginate worklog collection, honour the sync range, and emit ids that join jira - #9164
Merged
Merged
Conversation
The worklog collector computed the page count from metadata.total, which the Tempo v4 API does not return (PageableMetadata only has count, offset, limit, next and previous). The page count was therefore always zero and only the first page (1000 worklogs) was ever collected. Per team, the collector also ignored the sync policy and always asked for a rolling window of the last 90 days, so it kept re-fetching the oldest 1000 worklogs of that window and never reached recent ones. - Drop GetTotalPages so pages are fetched until one comes back short. - Full sync starts at timeAfter; incremental runs use updatedFrom with the last successful collection time; explicit fromDate/toDate options still win. Same bounds for the team and the global endpoints. - Scope raw data and collector state per team (TeamId in the params, as TempoTeam.GetParams already declares), so team scopes of the same connection no longer share one incremental state; the extractor tags worklogs with their team and the convertor converts one team at a time.
The convertor wrote issue ids as jira:JiraIssues:<conn>:<id> (plural) while the jira plugin generates jira:JiraIssue:<conn>:<id>, and stored the author as the bare Atlassian account id instead of the jira:JiraAccount:<conn>:<id> domain id. Tempo worklogs therefore never joined issues, accounts or the team/user mapping. Generate both ids in the jira plugin's format. buildIssueIdMapping is removed: both of its branches produced the same string, so the extra scan of _tool_jira_issues had no effect.
pballester
force-pushed
the
fix/tempo-worklog-pagination
branch
from
September 23, 2026 19:40
cc36dae to
0c2d8d9
Compare
klesh
approved these changes
Sep 24, 2026
klesh
left a comment
klesh
left a comment
Contributor
There was a problem hiding this comment.
LGTM
Thanks for your contribution.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes the Tempo worklog collection and conversion described in #9163 — full diagnosis and evidence there. Two commits, kept separate for review:
1.
fix(tempo): paginate worklogs and honour the sync time rangeGetTotalPages: Tempo v4PageableMetadatahas nototal, so the page count was always 0 and only the first 1000 worklogs were collected. The collector now uses the helper's undetermined mode and fetches pages until one comes back short.buildWorklogQuery: full sync →from=timeAfter; incremental →updatedFrom=<last successful collection>; explicitfromDate/toDateoptions still win. Same bounds for the team and global endpoints (previously the team endpoint always used a rollingnow − 90dwindow).TeamIdin the params, matchingTempoTeam.GetParams()), so team scopes of one connection no longer share one incremental state. The extractor tags worklogs with theirteam_id; the convertor converts one team at a time.2.
fix(tempo): emit worklog issue and author ids that join the jira domainissue_id:jira:JiraIssue:<conn>:<id>(wasJiraIssues, which matches nothing the jira plugin generates).author_id:jira:JiraAccount:<conn>:<id>(was the bare Atlassian id).buildIssueIdMappingremoved: both branches produced the identical string, so the_tool_jira_issuesscan had no effect.As before, the convertor assumes the Tempo connection id equals the Jira connection id; not changed here to keep the scope tight — happy to follow up (e.g. a scope-config field for the Jira connection) if maintainers want it.
Upgrade note: existing raw rows were stored with
TeamId: 0params, so after this change each team starts with a fresh collector state and does one full sync fromtimeAfter. Domain rows keep the same ids (tempo:TempoWorklog:<id>) and are overwritten in place.Tests
TestBuildWorklogQuery(pagination, full vs incremental bounds, explicit options, global endpoint).TestWorklogExtraction(team-scoped raw params →team_idpopulated); verified it fails without the fix.TestWorklogDataFlowsnapshot updated to the corrected ids.go vet/gofmtclean;golangci-lintreports no new findings in the plugin; e2e run against MySQL 8.0.Does this close any open issues?
Closes #9163
Screenshots
N/A