[GitHub] Workflow runs with in_progress status are skipped and not collected after completion

[vasukiiyengar98]

Hi DevLake team,

We are using Apache DevLake v1.0.2 with the GitHub plugin to collect GitHub Actions workflow runs.

Our DevLake deployment is running on AWS ECS. We have created the required ECS containers/services using the official Apache DevLake Docker images.

We have some GitHub Actions workflows that run for several hours. During the "Collect Workflow Runs" task, DevLake logs messages like:

Skipping run{id: 3372***, number: 1158***} with status in_progress
Skipping run{id: 3372***, number: 303***} with status in_progress

Our concern is that these workflow runs are skipped while they are still in_progress.

Later, when the GitHub Actions workflow finishes and its status changes to completed, a subsequent incremental sync does not appear to collect or update the previously skipped workflow run.

Our expected behavior is:

1. Detect the workflow run while it is in_progress.
2. Keep it as an unfinished/in-progress run.
3. Re-check the run during subsequent syncs.
4. Once GitHub reports the run as completed, update the existing workflow run record.

Could you please confirm:

• Is this expected behavior in DevLake v1.0.2?
• Is there any configuration that makes DevLake re-check in_progress workflow runs during later syncs?
• Has this behavior been fixed or changed in a newer DevLake version?
• If not, what is the recommended approach for handling long-running GitHub Actions workflows?

Since our DevLake deployment is running on AWS ECS using the official DevLake Docker images, we would prefer to use a supported configuration or upgrade rather than maintain a custom DevLake code/image if possible.

Any guidance on the recommended approach would be greatly appreciated.

Thanks!

[tomm1990]

In backend/plugins/github/tasks/cicd_run_collector.go (tag v1.0.2) Collect Workflow Runs only keeps runs with status == "completed". Anything else (including in_progress) is logged as Skipping run{id: ..., number: ...} with status ... and discarded. Nothing is written for those IDs, so a later sync cannot “update the existing unfinished record.”

that skip is expected in v1.0.2, and there is no toggle to “keep in_progress and update later.”

Worse for multi-hour Actions: that collector is finalizable on created_at. Incremental sync advances since from collected completed runs. A long run that was skipped while in progress still has the old created_at. Once since moves past that timestamp, a later completed sync may never walk back far enough to see it again. That matches what you are seeing.

Current main still filters to completed only (it got quieter about the skip log and uses created=from..to windows). So upgrading the official image alone does not give you “store in_progress then patch on completion.”

Practical options without a custom image:

1. After long workflows finish (or on a schedule), run a full sync (or a collect with timeAfter / time range that covers those runs’ created_at), so the completed rows are listed again.
2. Keep incremental for day-to-day, and treat full/backfill sync as the safety net for hour-scale jobs.
3. If you need true in-progress tracking, that is a product change (persist non-completed + refresh by id/updated_at). Worth an issue against apache/devlake with your ECS image tag and the skip log lines.

If you can paste one skipped run id and whether a full sync afterward creates the _tool_github_runs row, that confirms the created_at window miss vs a different filter problem.

[vasukiiyengar98]

@tomm1990 , Thanks a lot for your detailed explanation and for taking the time to look into this. I really appreciate your help.
I’ll go through the steps and test the workaround on our setup. If I face any issues or have any questions while testing, I’ll update them here. Thanks again for your support!

[tomm1990]

@vasukiiyengar98 sounds good - once Full Refresh Mode / the fullSync: true trigger picks up a previously skipped run, please mark an answer on this thread so the next ECS + long Actions setup finds it. if something still misses after that, paste the run id + whether _tool_github_runs got the row and we can dig from there.

[vasukiiyengar98]

Hi @tomm1990, I tested the Full Refresh approach with the Time Filter set to 1 month. manually running the workflow

Our current DevLake version is v1.0.2.

The Full Refresh completed successfully, but after the refresh I noticed that a significant amount of data that was previously visible in our Grafana dashboard is now missing. I compared the dashboard before and after the Full Refresh, and the difference is quite noticeable.

I also checked the GitHub collector logs, and the Full Refresh is still skipping multiple workflow runs with in_progress status.

So it looks like the Full Refresh is re-collecting the data within the Time Filter, but it is still skipping in_progress runs, and it also doesn't seem to restore all of the data we previously had.

Could you please help me understand what might be happening here? Is there anything else I should check in the Time Filter or Full Refresh configuration before we proceed further?

Also, since we are currently using v1.0.2, is there any newer DevLake version that has resolved or improved this type of GitHub Actions workflow-run issue? If so, could you please let me know which version you recommend? I can test the newer version in our environment before going further with the workaround.

Thanks again for your help and for taking the time to look into this.

[klesh]

I don't recall this issue was fixed in newer version.

[vasukiiyengar98]

Hi @klesh, thanks for your reply!

I tried the Full Refresh approach suggested by @tomm1990, but unfortunately, after the refresh I lost some of the data that was previously available.

If this issue with in_progress workflow runs has been fixed or improved in any newer version, upgrading would be very useful for us, since we need to retain and track all workflow-run data from the past few months. Skipping these runs doesn’t seem like a reliable solution.

I’m also not sure how others have worked around this issue. If there’s anything else I can try from my side, please let me know.

Thanks again for your help!

[NhanDuong21]

There is now an upstream fix for this, newer than the replies above: #9162 was merged on September 24 and is included in v1.0.3-beta18.

The collector now stores unfinished runs and revisits the oldest unfinished run when choosing the next incremental collection window. That lookback is bounded to 14 days, so your 3–4-hour workflows fall within it. This does not require a custom image.

I would back up the database, test the beta18 release images in a staging copy of your ECS deployment, and check one known run through both in_progress and completed using your existing two-hour incremental schedule. The release's Compose attachment lists the matching backend, Config UI and dashboard image tags.

One important distinction: runs discarded by v1.0.2 are not automatically recovered by the new unfinished-run tracking. The fix documents a one-time backfill with TimeAfter covering their creation dates. Since your previous full refresh removed dashboard history, do not repeat a one-month refresh on production without a backup and a staging test covering the full history you intend to retain. Data that GitHub no longer exposes may require restoring your earlier backup.