[Bug][Tempo] Worklog domain ids lack the connection id, so connections with the same worklog id overwrite each other
Maintainer antworten meist innerhalb von 2 Tagen
Bewertung
- Schwierigkeit
- 2/5
- Geschätzter Aufwand
- 1-3 Stunden
- Anfängerfreundlichkeit
- 78/100
- Issue-Typ
- Bug
- Klarheit
- Klar beschrieben
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- go
- Bereich
- data-engineering
Rechercherichtung
Beginne mit backend/plugins/tempo/tasks/worklog_convertor.go und untersuche, wie dort die Domain-ID des Worklogs erstellt wird; vergleiche sie mit dem Primärschlüssel von TempoWorklog und den anderen verbindungsspezifischen IDs, die im Issue beschrieben werden. Füge einen Unit-Test hinzu, der identische Worklog-IDs aus zwei Verbindungen abdeckt. Fertig ist die Arbeit, wenn jede Verbindung eine eigene issue_worklogs-Zeile erzeugt und der Test besteht.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Search before asking
- I had searched in the issues and found no similar issues.
What happened
The Tempo convert_worklogs subtask (backend/plugins/tempo/tasks/worklog_convertor.go) builds the issue_worklogs id from the Tempo worklog id alone:
domainWorklogId := fmt.Sprintf("tempo:TempoWorklog:%d", tempoWorklog.TempoWorklogId)
The tool layer keys worklogs by (connection_id, tempo_worklog_id) (models.TempoWorklog), and the other ids of the same row (jira:JiraIssue:<conn>:<id>, jira:JiraAccount:<conn>:<id>) carry the connection id. Domain ids that didgen generates for other plugins carry it too. The worklog id doesn't.
So when two Tempo connections have a worklog with the same tempoWorklogId (two connections to the same Tempo instance, or two instances whose worklog ids overlap), both convert to the same issue_worklogs primary key. The connection converted last overwrites the other connection's row (its issue_id, author_id and _raw_data_params), so one of the two worklogs disappears from the domain layer.
Example: connection 1 and connection 2 both have worklog 12345. After converting connection 1 and then connection 2, issue_worklogs has one row, tempo:TempoWorklog:12345, which points to jira:JiraIssue:2:.... Connection 1's worklog is gone. Re-running connection 1 brings it back and drops connection 2's.
What do you expect to happen
Each connection's worklog gets its own domain row: tempo:TempoWorklog:<connectionId>:<tempoWorklogId>, the id didgen would generate from the TempoWorklog primary key.
How to reproduce
- Create two Tempo connections (ids 1 and 2) that both return a worklog with the same
tempoWorklogId. - Collect, extract and convert worklogs for a team scope of each connection.
SELECT id, issue_id, _raw_data_params FROM issue_worklogs WHERE id LIKE 'tempo:%'shows one row for that worklog instead of two.
Anything else
Proposed fix (I have a PR ready): add the connection id to the domain worklog id and add a unit test. No migration is needed: the converter is a full-sync DataConverter, so its first batch deletes the scope's old rows (same _raw_data_table / _raw_data_params) before it saves the rows with the new ids.
Version
main
Are you willing to submit PR?
- Yes I am willing to submit a PR!
Code of Conduct
- I agree to follow this project's Code of Conduct
- Vorherrschende Sprache
- Go
- Sterne
- 3.2k
- Forks
- 832
- Ø Merge
- 2 T. 6 Std.
- Gemergte PRs (30 T.)
- 86
Entwicklungsumgebung
Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Kein Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus apache/devlake
-
[Bug][Testmo] Runs, milestones and automation runs: only the first 100 are collectedEvtl. vergeben @ShivamSharma43 hat das vor 2 Tagen übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 2 Tagen
-
[Bug][linker] LinkPrToIssue never matches lowercase issue keys (e.g. in branch names)Evtl. vergeben @VictorColomb hat das vor 6 Tagen übernommen. Offentype/bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
apache/devlake#9283 · 1 Kommentar · 1 Reaktion · 1 zugewiesene Person ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 60/100
Maintainer antworten meist innerhalb von 2 Tagen
-
type/bug
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 51/100
Maintainer antworten meist innerhalb von 2 Tagen
-
[Bug][JIRA Service API TOKEN] Jira API Gateway: saved service-account token truncated by varchar(255), causing Base64 errors and HTTP 500Evtl. vergeben @RyoKusnadi hat das vor 2 Tagen übernommen. Offentype/bug
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 58/100
apache/devlake#9328 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 2 Tagen
Ähnliche Issues
-
[v3] KeyBindingManager calls (Add/Remove) are not converted into a case-insensitive accelerator.KeyOffenBug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag
-
runtime: usleep sleeps nanoseconds instead of microseconds on linux/mips and linux/mips64Evtl. vergeben @BRobertson7 hat das heute übernommen. Offencompiler/runtime
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
golang/go#82913 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
-
bug needs-triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
aws/aws-sdk-go-v2#3625 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 67/100
adrianbrad/queue#92 ·