[Bug][Github] Incorrect datetime value: '0000-00-00' for column 'started_at'

Search before asking

I had searched in the issues and found no similar issues.

What happened

When running the pipeline against a github repo that was working normally, this started to appear. I don't know why this started. The other repos here (5+) are all working fine.

What do you expect to happen

I would expect this not to happen.

How to reproduce

I do not know how to reproduce it. The other projects are not having this error.

Anything else

No response

Version

v1.0.1

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

@gbrancaglione

Hello @gbrancaglione! I'm here to help you tackle any bugs, answer questions, and assist you in becoming a contributor while you wait for a human maintainer. Let's get to the bottom of this! 🤖

The MySQL error "Incorrect datetime value: '0000-00-00' for column 'started_at'" is likely caused by the StartedAt field in the DbCheckRun struct being set to a zero date value ('0000-00-00'). MySQL does not accept '0000-00-00' as a valid date unless the SQL mode is configured to allow it, which is not the default behavior.

To resolve this issue, ensure that the StartedAt field is initialized with a valid datetime value before it is inserted into the database. You can add a check in the Extract function to handle cases where checkRun.StartedAt is '0000-00-00' and set it to a valid default datetime or handle it according to your application's requirements. Here's a code snippet to handle this:

if checkRun.StartedAt == "0000-00-00" {
    checkRun.StartedAt = "1970-01-01" // or any other default valid datetime
}

This check should be added before the githubJob struct is created in the Extract function ^[1].

To reply, just mention @dosu.

Docs are dead. Just use Dosu.

Try the latest beta. https://github.com/apache/incubator-devlake/releases/tag/v1.0.2-beta8

This bug is related to #8214. It is solved, but it is not associated with any version. What's the procedure for adding it to a release?

We've the same issue.
Would be nice to know for sure, which version or release-candidate will contain the fix.

Try the latest beta. v1.0.2-beta8 (release)

It fixed the initial sync (latest 14 days), but then I tried to get older data (last year) and it started failing again. Even in v1.0.2-beta8

Maybe we should skip those records without started_at value?
What do you guys think.

Maybe we should skip those records without started_at value? What do you guys think.

That sounds good. Is it possible to configure somehow directly while importing records? I've set 'skip failed tasks' after the initial sync and increased timeline from "last 14 days" to "last year". While showing 'partial success' in tasks it still doesn't update values in grafana dashboards (they show last 14 days).

What extra steps can I take to load only what loads correctly and see the full picture? Thank you in advance for your support

Try the latest beta. v1.0.2-beta8 (release)

It fixed the initial sync (latest 14 days), but then I tried to get older data (last year) and it started failing again. Even in v1.0.2-beta8

I can confirm this issue still exists in v1.0.2-beta9.

Also still exists in v1.0.3-beta1.
Can we skip records for now that have invalid date time?

fix(github): skip jobs with no started_at in cicd_job_convertor

Maybe we should skip those records without started_at value? What do you guys think.

I've opened a small PR with your proposed fix, would you be able to have a look at that please?
#8488

@Brend-Smits

@Brend-Smits . Good job, thanks for the PR.

@petkostas

@klesh @d4x1 shall we create a new release v1.0.4-beta1 for this? since we addressed the issue in v1.0.4-alpha

I think you can release a v1.0.4-alpha1 on the main branch if possible. @petkostas

Is there anything preventing the fix from landing in 1.0.3?

@jekader

@jekader It’s a bit unconventional to have a v1.0.4-alpha change released into a v1.0.3-betax version, since it mixes versions in a way that could be confusing. That said, I’m open to it if everyone else is aligned.

@petkostasI
recommend including this fix in the v1.0.3 release line since it's currently in beta. Using v1.0.4-alpha for this change was likely premature given our release schema:

v1.0.3-beta1 → v1.0.3-beta2 → ... → v1.0.3 (stable) → v1.0.4-alpha → ...

@d4x1

Since v1.3.0-beta7 was released I will be closing this ticket! Kudos to @d4x1 🙏🏼

Deployed docker.io/apache/devlake:v1.0.3-beta7 and still getting the same error with GitHub:

subtask Extract Jobs ended unexpectedly Wraps: (2) error adding result to batch (500) Wraps: (3) Error 1292 (22007): Incorrect datetime value: '0000-00-00' for column 'started_at' at row 244 (500) Wraps: (4) Error 1292 (22007): Incorrect datetime value: '0000-00-00' for column 'started_at' at row 244 Error types: (1) *hintdetail.withDetail (2) *hintdetail.withDetail (3) *hintdetail.withDetail (4) *mysql.MySQLError

Is there anything specific that needs to be configured for this to go away?

I have also deployed devlake.docker.scarf.sh/apache/devlake:v1.0.3-beta7 and am still receiving the same error.

subtask Extract Jobs ended unexpectedly Wraps: (2) error adding result to batch (500) Wraps: (3) Error 1292 (22007): Incorrect datetime value: '0000-00-00' for column 'started_at' at row 366 (500) Wraps: (4) Error 1292 (22007): Incorrect datetime value: '0000-00-00' for column 'started_at' at row 366 Error types: (1) *hintdetail.withDetail (2) *hintdetail.withDetail (3) *hintdetail.withDetail (4) *mysql.MySQLError

This is the value it is trying to insert for the started_at 0000-00-00 00:00:00

Since v1.3.0-beta7 was released I will be closing this ticket! Kudos to @d4x1 🙏🏼

We've updated to v1.0.3-beta7 and the error is gone.
Thanks a lot for your work!

I've tried both v1.0.3-beta7 & v1.0.3-beta8 and the error is still there

@petkostas

I can confirm that we still see this bug on both v1.0.3-beta7 and v1.0.3-beta8
@petkostas should we reopen this one or open a new issue tracker?

I think I found the root cause of why some people still see the issue while it is reported as fixed: older installations use GitHub API to scrub data while GraphQL is used by default on new blueprints and this is what #8583 fixed.

There is no way to set the backend from the UI - removed in #7784 so existing pipelines still use the deprecated backend.

I updated the DB manually to get around this: UPDATE lake._tool_github_connections SET enable_graphql=1;

Will open an issue proposing always using GraphQL regardless of what the DB says.

Perhaps we should add a migration script for that.

fix(github): skip jobs with no started_at in cicd_job_convertor (apac…

Navigation Menu

Repository navigation

[Bug][Github] Incorrect datetime value: '0000-00-00' for column 'started_at' #8442

Search before asking

What happened

What do you expect to happen

How to reproduce

Anything else

Version

Are you willing to submit PR?

Code of Conduct

29 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug][Github] Incorrect datetime value: '0000-00-00' for column 'started_at' #8442

Description

Search before asking

What happened

What do you expect to happen

How to reproduce

Anything else

Version

Are you willing to submit PR?

Code of Conduct

Activity

dosubot commented on May 15, 2025

klesh commented on May 16, 2025

zvika-finally commented on May 19, 2025

Joerg-Tech commented on Jun 6, 2025

vadim-ilchenko commented on Jun 6, 2025

klesh commented on Jun 9, 2025

vadim-ilchenko commented on Jun 9, 2025

dsiebel commented on Jun 23, 2025

Brend-Smits commented on Jul 2, 2025

Brend-Smits commented on Jul 2, 2025

klesh commented on Jul 7, 2025

29 remaining items

d4x1 commented on Oct 15, 2025

jekader commented on Oct 15, 2025

petkostas commented on Oct 15, 2025

klesh commented on Oct 16, 2025

petkostas commented on Oct 20, 2025

ederevea commented on Oct 20, 2025

karl-d commented on Oct 28, 2025

Joerg-Tech commented on Oct 30, 2025

GGurbanov commented on Nov 18, 2025

jekader commented on Nov 18, 2025

jekader commented on Dec 16, 2025

klesh commented on Dec 18, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions