apparently in some cases tempo returns None as worklogid

[fizyk]

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]

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

[mmaslowskicc]

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]

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]

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

[mmaslowskicc]

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]

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.