[Question] Pipeline fails at "Convert Releases" with nil pointer dereference

[nkofficial-1005]

Explanation of the Issue:

Environment

DevLake Version: v1.0.4-alpha@7e7baa2
Deployment: Docker Compose
OS: macOS
Plugin: github_graphql

Description
Pipeline consistently fails at Stage 2, Task 62 (github_graphql:SWP-Cayman/swp-mono) during the "Convert Releases" subtask with a panic error:

run task failed with panic (github.com/apache/incubator-devlake/plugins/github/tasks.ConvertRelease.func1:76) 
Wraps: (2) runtime error: invalid memory address or nil pointer dereference 
Error types: (1) *hintdetail.withDetail (2) runtime.errorString

Status shown: Partial Success (9/8 tasks completed)

Stage that fails: Stage 2

Failed task: Task62 github_graphql:SWP-Cayman/swp-mono

What Actually Works
Despite the UI showing failure:

All previous subtasks complete successfully (Task54 org, Task56 gitextractor, Task57 Jira, Task58 refdiff)
Data collection is successful - all data appears in MySQL
The failure only occurs during the "Convert Releases" subtask
Other stages (1, 3, 4) were completed successfully

Checking MySQL confirms the data was collected:

SELECT COUNT(*) FROM pull_requests;  -- Returns full count
SELECT COUNT(*) FROM cicd_tasks;     -- Returns full count
SELECT COUNT(*) FROM issues;         -- Returns full count

Workaround
Skipping the release-related subtasks allows the pipeline to complete successfully:

curl -sS 'http://127.0.0.1:8090/blueprints/1' | python3 -c "

import json, sys, urllib.request

bp = json.load(sys.stdin)

# Remove release subtasks from github_graphql
release_tasks = {'Collect Releases', 'Extract Releases', 'Convert Releases'}
for stage in bp['plan']:
    for task in stage:
        if task.get('plugin') == 'github_graphql' and task.get('subtasks'):
            task['subtasks'] = [s for s in task['subtasks'] if s not in release_tasks]

# Trigger a one-off pipeline with this plan (not saving to blueprint)

payload = json.dumps({'name': 'manual-no-releases', 'plan': bp['plan']}).encode()
req = urllib.request.Request('http://127.0.0.1:8090/pipelines', data=payload, method='POST')
req.add_header('Content-Type', 'application/json')
resp = urllib.request.urlopen(req)
result = json.loads(resp.read())
print('Pipeline ID:', result.get('id'), '| Status:', result.get('status'))

This creates a pipeline without the release subtasks and runs successfully.

Expected Behavior
The "Convert Releases" subtask should either:

Complete successfully, or
Handle the nil pointer gracefully without causing a panic

Actual Behavior
Pipeline fails with panic, showing "Partial Success" status even though all other data collection completed successfully.

Questions

1. Is this a known issue with the release conversion process?
2. Should releases be optional/skippable in the UI configuration?
3. Is the nil pointer dereference at line 76 in ConvertRelease.func1 related to malformed release data?
4. Is it safe to run DevLake without release collection, or will this break DORA metrics?

Screenshot

Additional Context

This issue prevents using the UI "Run Now" button reliably
The workaround requires API access and custom scripting
Makes it difficult to set up DevLake for non-technical users
All other data (PRs, commits, issues, deployments, workflows) is collected successfully

[dosubot]

Hi @nkofficial-1005! I'm Dosu and I’m helping the incubator-devlake team.

This is a documented bug where the ConvertRelease function panics because the PublishedAt field on a GithubRelease can be nil (it was a *time.Time pointer type), and the converter dereferences it without a nil check [1]. Draft releases from GitHub have no PublishedAt value, which triggers the panic. PR #8628 reported a 100% failure rate for all repositories with releases at this step [2].

This has been addressed in more recent versions through multiple fixes:

• PR Fix/8538 GitHub zero time #8583 introduced a NilIfZeroTime utility to normalize nil/zero time values across the GitHub plugin [3].
• PR fix: drafting releases should not be converted to domain layer #8625 added database-level filtering for draft releases [4].
• The PublishedAt field was eventually changed from *time.Time (pointer) to time.Time (value type), eliminating the nil dereference entirely [5].

To answer your specific questions:

1. Yes, this was a bug that has been fixed in newer versions. Upgrading from v1.0.4-alpha should resolve it.
2. Skipping release subtasks is a valid workaround (as you've already discovered).
3. Yes — the nil pointer at line 76 is specifically caused by releases with a nil PublishedAt (e.g., draft releases).
4. It is safe to run without release collection. DORA metrics rely on deployments and PRs/incidents, not GitHub Releases, so skipping release subtasks will not affect DORA calculations.

Recommendation: Upgrade to a newer version of DevLake where this is fixed. If you must stay on v1.0.4-alpha, your workaround of skipping the release subtasks is the right approach.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[klesh]

Why are you using an Alpha version? It is intended for internal testing by developers only. Additionally, the version you are using is quite old. Could you try the latest v1.0.3 beta instead?

[nkofficial-1005]

Yes, I tried with that, and it resolved the issue. Thanks a lot for the help!