actions task displays an incorrect time #12138

Closed
opened 2025-11-02 09:59:47 -06:00 by GiteaMirror · 5 comments
Owner

Originally created by @ExplodingDragon on GitHub (Dec 2, 2023).

Description

I'm using sqlite and found this bug during a routine weekly check, not sure how to reproduce it for now.

图片
图片
图片

Gitea Version

main

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

systemd

Database

SQLite

Originally created by @ExplodingDragon on GitHub (Dec 2, 2023). ### Description I'm using sqlite and found this bug during a routine weekly check, not sure how to reproduce it for now. ![图片](https://github.com/go-gitea/gitea/assets/33776693/a1f7d2fa-e8d3-40f6-a64f-a899fb770b4d) ![图片](https://github.com/go-gitea/gitea/assets/33776693/247f33c3-c0dd-44e4-a129-f0de249a7daf) ![图片](https://github.com/go-gitea/gitea/assets/33776693/bd03fe57-9ba2-4589-9a3f-a35ddf677bcc) ### Gitea Version main ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? systemd ### Database SQLite
GiteaMirror added the type/bug label 2025-11-02 09:59:47 -06:00
Author
Owner

@yp05327 commented on GitHub (Dec 5, 2023):

The duration in the first pic is calculated by the records in action_run table,
and in the second pic, it is calculated by the records in action_task_step table.
So it seems that the data in action_task_step table is correct but the data in action_run table is incorrect.

@yp05327 commented on GitHub (Dec 5, 2023): The duration in the first pic is calculated by the records in `action_run` table, and in the second pic, it is calculated by the records in `action_task_step` table. So it seems that the data in `action_task_step` table is correct but the data in `action_run` table is incorrect.
Author
Owner

@yp05327 commented on GitHub (Dec 5, 2023):

It seems that this run was scheduled twice.

yesterday (above the wrong duration) is Updated time. Not the Started time and Stopped time.
And the schedule is weekly, and the run before this run is 2 weeks ago, so the last updated time of this run should be 1 weeks ago? But it is yesterday here.

So I guess: yesterday it was scheduled again (or maybe other operations?) , and the Started time was updated.
But this run is already been done, so the status should be done and it would not run again.
So the Stopped time should be the last stopped time which won't be updated for ever, so the duration becomes minus number here.
So if my guess is correct, the date of yesterday would be about 105h37m21s after the real Stopped time.

@yp05327 commented on GitHub (Dec 5, 2023): It seems that this run was scheduled twice. `yesterday` (above the wrong duration) is `Updated` time. Not the `Started` time and `Stopped` time. And the schedule is `weekly`, and the run before this run is `2 weeks ago`, so the last updated time of this run should be `1 weeks ago`? But it is `yesterday` here. So I guess: `yesterday` it was scheduled again (or maybe other operations?) , and the `Started` time was updated. But this run is already been done, so the status should be done and it would not run again. So the `Stopped` time should be the last stopped time which won't be updated for ever, so the duration becomes minus number here. So if my guess is correct, the date of `yesterday` would be about `105h37m21s` after the real `Stopped` time.
Author
Owner

@yp05327 commented on GitHub (Dec 6, 2023):

Ok, I got it. But don't know why. 🤔
image

@yp05327 commented on GitHub (Dec 6, 2023): Ok, I got it. But don't know why. 🤔 ![image](https://github.com/go-gitea/gitea/assets/18380374/bc8ae551-49ca-4fa4-abd6-02b81ed4fd9b)
Author
Owner

@yp05327 commented on GitHub (Dec 6, 2023):

This issue is not related to cron job.
And there's a easy way to reproduce:

  • stop all your runners which can pick up the workflow.
  • trigger the workflow, and the status will be waiting as there's no runners to run it.
  • cancel it, the status will become failure.
  • start your runner, rerun it
  • after it finished, you will get a minus duration time.

I will try to fix it. This issue is caused by the codes here:
876a0cb3d6/models/actions/run_job.go (L140-L146)
When a job finished before executed once, e.g. no target runner and canceled manually, the Stopped time is not 0 but the Started time is 0.
So if you rerun it, only Started time will be updated, but the Stopped time won't. Then you will get a minus duration time, as it is calculated by Stopped - Started.

@yp05327 commented on GitHub (Dec 6, 2023): This issue is not related to cron job. And there's a easy way to reproduce: - stop all your runners which can pick up the workflow. - trigger the workflow, and the status will be waiting as there's no runners to run it. - cancel it, the status will become failure. - start your runner, rerun it - after it finished, you will get a minus duration time. I will try to fix it. This issue is caused by the codes here: https://github.com/go-gitea/gitea/blob/876a0cb3d652f42545abdb33dc4fd71a7c3343bf/models/actions/run_job.go#L140-L146 When a job finished before executed once, e.g. no target runner and canceled manually, the `Stopped` time is not `0` but the `Started` time is `0`. So if you rerun it, only `Started` time will be updated, but the `Stopped` time won't. Then you will get a minus duration time, as it is calculated by `Stopped - Started`.
Author
Owner

@github-actions[bot] commented on GitHub (Mar 1, 2024):

Automatically locked because of our CONTRIBUTING guidelines

@github-actions[bot] commented on GitHub (Mar 1, 2024): Automatically locked because of our [CONTRIBUTING guidelines](https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md#issue-locking)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#12138