Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

[Bug][tempo] Worklog collector only fetches the first 1000 worklogs of a rolling 90-day window; converted ids don't join jira

已关闭
  • 哪里不对？
#9,163 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 3 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
45/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
go
领域
backend, data-engineering

调研方向

The bug is in backend/plugins/tempo/tasks/worklog_collector.go. Start by reading the collector's pagination logic and the Tempo v4 API spec. Check how the time range is set for team scopes and how raw params are shared. For the conversion issues, examine the ID generation in the worklog converter. Run the existing tests and create a test connection to verify fixes.

由索引模型根据 Issue 内容生成。

描述

Search before asking
  • I had searched in the issues and found no similar issues.
What happened

On a Tempo connection with team scopes, collect_worklogs never collects more than 1000 worklogs per team, and they are always the oldest ones of a rolling 90-day window — recent worklogs never arrive. Seen on v1.0.3-beta15; the collector is unchanged on main.

Evidence from _raw_tempo_api_worklogs after ~50 daily runs:

  • every request URL has offset=0, e.g. https://api.tempo.io/4/worklogs/team/4?from=2026-06-25&limit=1000&offset=0&to=2026-09-23, and each returns exactly 1000 results, i.e. there were more pages that were never requested;
  • from is always today − 90 days, regardless of the blueprint's timeAfter (2026-01-28 here);
  • resulting _tool_tempo_worklogs by start month: May 5040, Jun 5109, Jul 2208, Aug 461, Sep 46 — nothing before May, and a steady decline towards today, while the same teams log a roughly constant volume.

Root causes in backend/plugins/tempo/tasks/worklog_collector.go:

  1. Pagination — GetTotalPages computes the page count from metadata.total, but the Tempo v4 API does not return a total: per the official OpenAPI spec (https://apidocs.tempo.io/tempo-openapi.yaml), PageableWorklog.metadata is PageableMetadata = count, limit, next, offset, previous. total unmarshals as 0 → 0 pages → only the first page is fetched.
  2. Time range — for team scopes the query uses from = now − 90d / to = now unless fromDate/toDate task options are set (the blueprint never sets them), ignoring the sync policy (timeAfter, incremental state).
  3. Shared state across teams — the collector's raw params only carry ConnectionId (TeamId is always 0, although TempoTeam.GetParams() declares ConnectionId + TeamId), so all team scopes of a connection share one raw-data/collector-state key. With (2) fixed, the second team collected in a pipeline would run incrementally from the first team's start time.

Separately, convert_worklogs emits ids that never join the jira domain layer:

  1. issue_worklogs.issue_id is jira:JiraIssues:<conn>:<id> (plural), while the jira plugin generates jira:JiraIssue:<conn>:<id>;
  2. issue_worklogs.author_id is the bare Atlassian account id instead of jira:JiraAccount:<conn>:<id>, so worklogs don't join accounts / user_accounts.
What do you expect to happen

All worklogs from timeAfter onwards are collected (then incrementally via updatedFrom), and issue_worklogs rows join issues and accounts like the jira plugin's own worklogs do.

How to reproduce
  1. Create a Tempo connection and add a team scope whose members log more than 1000 worklogs in 90 days.
  2. Run a blueprint with timeAfter older than 90 days.
  3. SELECT url, COUNT(*) FROM _raw_tempo_api_worklogs GROUP BY url; → one URL per run, offset=0, 1000 rows each; SELECT MIN(start_date), MAX(start_date) FROM _tool_tempo_worklogs; → starts 90 days back, sparse towards today.
  4. SELECT COUNT(*) FROM issue_worklogs w JOIN issues i ON i.id = w.issue_id WHERE w.id LIKE 'tempo:%'; → 0.
Anything else

Happens on every run. Worklogs collected by the jira plugin for time logged through Tempo carry the "Timesheets by Tempo" app as author, so the tempo plugin is the only source of per-person time — which makes this quite visible for anyone building per-team/per-person dashboards.

Version

v1.0.3-beta15 (collector unchanged on main)

Are you willing to submit PR?
  • Yes I am willing to submit a PR!
Code of Conduct
主要语言
Go
星标
3.2k
派生
819
平均合并
2 天 21 小时
30 天内合并 PR
46

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

  • 没有 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

apache/devlake 的其他 Issue

查看 apache/devlake 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。