ClearcodeHQ / jira_timemachine

Project used to migrate worklogs between two jira instances and kind of keep it up to date
Other
2 stars 3 forks source link

apparently in some cases tempo returns None as worklogid #22

Open fizyk opened 3 years ago

fizyk commented 3 years ago

What action do you want to perform

Migrate worklogs to from source jira to destination

What are the results

Fails on exception when reading data from destiantion jira (no worklog id)

What are the expected results

Dat ais migrated. Apparently we've got either jiraWorklogid OR tempoWorklogID we could require one or the other. Plus, destination ought to have all required data for confirmation within worklog message.

fizyk commented 3 years ago

trying to update the issue seems to also solve the problem though ;)

mmaslowskicc commented 3 years ago

So one of the IDs is initially missing, but a following request gets both? We cannot choose the other ID for this reason, since it will duplicate worklogs on a rerun.

I don't see any other solution than skipping the worklog with a warning and optionally retrying.

fizyk commented 3 years ago

the issue was with the additional worklog in desitination jira. Apparently tempo stored the worklog but I think it failed to push it to the jira itself, hence the lack of the jiraWorklogID. while fixing, I updated the worklog, and the jiraWorklogID appeared.

I think that if we run sync through tempo, we can safely require the tempo id ( https://tempo-io.github.io/tempo-api-docs/#worklogs ) the tempoWorklogId is required. Jira's is not.

mmaslowskicc commented 3 years ago

Yes: if only jiraWorklogID is missing and it's not currently used, then it's ok to not require it.

mmaslowskicc commented 3 years ago

When I observed this issue, the Jira ID did not reappear, but I always synchronize only the current day. My current workaround:

diff --git a/src/jira_timemachine/__init__.py b/src/jira_timemachine/__init__.py
index 3c0bcc3..29d3f64 100644
--- a/src/jira_timemachine/__init__.py
+++ b/src/jira_timemachine/__init__.py
@@ -106,7 +106,7 @@ class TempoClient(object):
                     continue
                 try:
                     yield Worklog(
-                        id=int(row['jiraWorklogId']),
+                        id=int(row['jiraWorklogId'] or row['tempoWorklogId']),
                         tempo_id=int(row['tempoWorklogId']),
                         author=row['author']['accountId'],
                         started=arrow.get('{startDate} {startTime}'.format(**row)),

Since there is a potential case of worklog duplication, I think this might need an option for the user to choose which one to use.

mmaslowskicc commented 1 year ago

This still occurs, at least when I use TempoClient in my own script.

Censored output message:

Encountered an error int() argument must be a string, a bytes-like object or a real number, not 'NoneType' while processing a worklog entry {'self': 'abc', 'tempoWorklogId': 123, 'jiraWorklogId': None, 'issue': {'self': 'abc', 'key': 'abc', 'id': 123}, 'timeSpentSeconds': 123, 'billableSeconds': 123, 'startDate': '2023-04-28', 'startTime': '00:00:00', 'description': 'abc', 'createdAt': '2023-04-28T00:00:00Z', 'updatedAt': '2023-04-28T00:00:00Z', 'author': {'self': 'abc', 'accountId': 'abc', 'displayName': 'abc'}, 'attributes': {'self': 'abc', 'values': []}}

Rerunning the script makes it succeed.

Tempo now has a new API, version 4.0, that "solves" this by not including the Jira worklog ID: https://help.tempo.io/cloud/en/tempo-timesheets/developing-with-tempo/tempo-api-version-4-0-vs--version-3-0--a-comparison.html.

I think the correct solution is to migrate to Tempo worklog IDs.