pballester opened a new pull request, #9200:
URL: https://github.com/apache/devlake/pull/9200
### Summary
Follow-up to #9164 (released in v1.0.3-beta18): full syncs of the Tempo
plugin fail in `collect_worklogs`.
For a full sync, `buildWorklogQuery` sets `from=<timeAfter>` and no `to`.
Tempo rejects that period on every page, starting at offset 0:
```
GET worklogs/team/13?from=2026-01-28&limit=1000&offset=0
{"errors":[{"message":"Non valid period, from '2026-01-28' to 'null'"}]}
(400)
```
This hits every full sync, and also the **first run of every team after
upgrading to beta18**, since #9164 scopes the collector state per team so each
team starts fresh. Before #9164 the team endpoint always sent both `from` and
`to` (`to` defaulting to today); the OpenAPI spec lists both as optional, but
the API requires `to` when `from` is set.
**Fix:** whenever the query has `from` and no `to`, set `to` to the date the
collection started, computed once so every page asks for the same period. This
covers the full sync and a lone `fromDate` option. Incremental runs keep using
`updatedFrom` on its own, which Tempo accepts on both endpoints.
**Tests**
- `TestBuildWorklogQuery`: the full-sync and global-endpoint cases now
expect `to` (the previous test asserted it was empty, which encoded the bug);
new case for a `fromDate` option alone.
- Tempo e2e suite passes on MySQL 8.0; `gofmt`/`go vet` clean;
`golangci-lint` reports nothing new in the plugin.
### Does this close any open issues?
Follow-up to #9164 / #9163.
### Screenshots
N/A
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
