[Question]: Starting/Stopping of time tracking

[timkley]

What is your question?

We are currently implementing a way to start/stop time tracking from another tool.

We used the endpoints described here.

This is the payload for starting a time tracking:

{
    "taskId": "d421fc84-47a4-4f1d-863d-c81ed1b5d6bc",
    "timezone": "Europe/Berlin"
}

We do not send any payload when stopping the time tracking.

Sometimes, we notice that after a time tracking is stopped (either when calling users/{id}/timetracking/stop or when starting another time tracking), the previous time entry's startTime is somehow edited. It always receives the same start time as the next time entry.

I looked into the network requests of the awork app, and the payloads look very different. More data is sent, such as the startTime when starting a tracking or the timezone when stopping a tracking.

I don't want to rely on trial and error, so could you let me know if the API documentation might not be up to date?

Do you have a trace id of the call?

Unfortunately I can't provide a trace-id right now. We have a lot of requests going on and since it is not always happening its hard to pinpoint it.

I really hope it is just a documentation issue 😅

[vdurante]

Hey @timkley, thanks for reporting the issue.

Unfortunately, I was not able to reproduce the issue, but maybe I could investigate further if I could build a reproduction case.

Let me see if I got the flow right:

1. POST /users/id/timetracking/start with the reduced payload you sent
2. POST /users/id/timetracking/stop without a payload
3. GET /timeentries filtering by the task you sent
4. Repeat this flow indefinitely since the issue doesn't always happen
5. Observe that sometimes the startTime (both UTC and Local) of the previous time tracking get overwritten by the most recent one

Is this correct?

[timkley]

@vdurante

Yes, thats mostly correct. But it seems like it is only happening after another task was started without stopping. But I also can't reproduce it, seems like a strange race-condition.

So the flow where I noticed it the most would be:

1. POST /users/id/timetracking/start with the reduced payload
2. POST /users/id/timetracking/start with the reduced payload using another taskId
3. POST /users/id/timetracking/stop without a payload

I've seen it happening between 2 and 3 as well as after 3.

Thanks for investigating!

[vdurante]

@timkley regarding the request model, the API docs are correct. The extra, undocumented values passed by the front-end are ignored by the back-end.

Regarding the issue itself, I built a test case and ran hundreds of times, but was not able to reproduce.

We don't discard the possibility of a race condition or some caching issue, but at this point in time, without reproduction, it is really hard to detect what is going on.

If you have any extra information and is able to reproduce consistently, please let us know. Even a trace id of the request that caused the malformed time entry could be enough for an investigation

Thanks for the help and reporting the bug!

[timkley]

@vdurante thank you very much. I will try to get back to you something to reproduce.

One thing though: could it be happening when a /timetracking/start gets send two times very fast, resulting in not correctly stopping the first call because technically it is not running because it is still being processed?

This could explain the situation. I of course don't know what exactly happens when timetrackings are stopped, but would assume something along the lines of "get all timetracking entities which have no endTime and set the end time".

[vdurante]

@timkley I could investigate that, but it raises a question on what is the use case for triggering multiple /timetracking/start in sequence for the same user?

[timkley]

@vdurante, there is definitely no real use case for this, and I'm pretty sure that it was a race condition on our end. Since implementing a lock so that only one request at a time can be triggered to /timetracking/start, the problem has disappeared.

The only question that remains is: should this still be handled differently internally to ensure there are no incorrect time trackings?

I'm closing here for now since I'm pretty sure this was a bug on our part. Thank you very much for your quick and thorough help!

[vdurante]

@timkley thanks for reporting it! I could check if we could do something on our end to prevent this issue from happening again!