Explain, err="unknown X-Github-Event #318

Open
opened 2026-05-28 03:24:11 +00:00 by guettli · 2 comments
guettli commented 2026-05-28 03:24:11 +00:00 (Migrated from codeberg.org)

Explain that error message. Why does it happen. How to fix?

2026/05/27 22:01:43 WARN failed to parse github payload err="unknown X-Github-Event in message: schedule"

https://codeberg.org/guettli/sharedinbox/actions/runs/916/jobs/1/attempt/1#jobstep-4-1

Explain that error message. Why does it happen. How to fix? > 2026/05/27 22:01:43 WARN failed to parse github payload err="unknown X-Github-Event in message: schedule" https://codeberg.org/guettli/sharedinbox/actions/runs/916/jobs/1/attempt/1#jobstep-4-1
guettlibot commented 2026-05-28 04:22:18 +00:00 (Migrated from codeberg.org)

Implementation Plan: Understanding and Fixing the 'unknown X-Github-Event in message: schedule' Warning

What the error means

The warning:

2026/05/27 22:01:43 WARN failed to parse github payload err="unknown X-Github-Event in message: schedule"

is logged by the Dagger CLI (v0.20.8) during its startup in the deploy-playstore CI job. When Dagger starts inside a GitHub-Actions-compatible CI environment, it detects GITHUB_ACTIONS=true and reads GITHUB_EVENT_NAME to set up CI telemetry / OpenTelemetry context. It then tries to parse the event payload file at GITHUB_EVENT_PATH.

The error message phrase "unknown X-Github-Event in message: schedule" borrows the HTTP webhook header name (X-Github-Event) to describe the event type. Dagger's payload parser knows how to handle standard GitHub webhook events like push and pull_request, but schedule is a workflow trigger type, not a webhook event type, so the parser does not recognise it and logs a WARN.

Why it happens

The warning appears in runs triggered by .forgejo/workflows/deploy.yml (which uses on: schedule: - cron: '0 * * * *'). When the workflow runs:

  1. Forgejo/Codeberg sets GITHUB_EVENT_NAME=schedule in the job environment.
  2. The step Publish Android to Play Store (jobstep-4) runs task publish-android, which calls dagger call publish-android ….
  3. The Dagger CLI initialises, detects it is running in CI, reads GITHUB_EVENT_NAME=schedule, and tries to decode the event payload.
  4. The schedule type is unknown to Dagger's payload parser → warning is logged.
  5. Dagger continues normally; the warning is non-fatal and the CI job succeeds.

The .forgejo/workflows/monitor.yml workflow also uses on: schedule, but it only runs python3 scripts/agent_loop.py monitor (no Dagger), so it is not affected.

Impact

None. The warning is purely cosmetic noise in the log. The deploy job itself completes successfully.

How to fix it

There are two independent tracks:

Track A – Upstream Dagger fix (proper long-term fix)

The root cause is that the Dagger CLI does not handle the schedule event type in its GitHub payload parser. The fix belongs in the Dagger project.

Action: File a bug / PR against github.com/dagger/dagger (the CLI, not the SDK) asking it to treat unknown / non-webhook event types (like schedule, workflow_dispatch, repository_dispatch) gracefully — either by silently skipping the payload parse or by logging at DEBUG level instead of WARN.

No changes to the sharedinbox repo are needed for this track.

Track B – Suppress at the sharedinbox level (short-term workaround)

If the warning is considered distracting, the simplest in-repo fix is to unset GITHUB_EVENT_NAME in the dagger-running steps of deploy.yml, so Dagger does not attempt CI payload detection:

File: .forgejo/workflows/deploy.yml

In each step that invokes a dagger call … command (currently Publish Android to Play Store, Build & Deploy APK to server, Build & Deploy Linux to server, Generate build history and deploy website), add:

env:
  GITHUB_EVENT_NAME: ""   # prevent Dagger from attempting schedule-payload parse

Risks: Unsetting GITHUB_EVENT_NAME may affect other Dagger telemetry / tracing metadata that keys off the event type. If Dagger Cloud traces are in use, CI run links might not be annotated with the trigger source. This is minor and acceptable.

Alternative: Upgrade dagger.io/dagger in ci/go.mod to a version that handles schedule events — check the Dagger changelog for fixes to CI event detection after v0.20.8.

Summary of files to change

Track File Change
A (upstream) (Dagger repo, not this repo) Add schedule / unknown-event handling to CLI CI payload parser
B (workaround) .forgejo/workflows/deploy.yml Add GITHUB_EVENT_NAME: "" env to each dagger-running step
B (upgrade) ci/go.mod + ci/go.sum Bump dagger.io/dagger to latest and re-vendor

Recommendation

Do Track A first — report the bug upstream. In the meantime, Track B (adding GITHUB_EVENT_NAME: "") is a low-risk one-liner in deploy.yml and eliminates the log noise immediately. Upgrading Dagger is also worth doing independently of this issue.

## Implementation Plan: Understanding and Fixing the 'unknown X-Github-Event in message: schedule' Warning ### What the error means The warning: ``` 2026/05/27 22:01:43 WARN failed to parse github payload err="unknown X-Github-Event in message: schedule" ``` is logged by the **Dagger CLI** (v0.20.8) during its startup in the deploy-playstore CI job. When Dagger starts inside a GitHub-Actions-compatible CI environment, it detects `GITHUB_ACTIONS=true` and reads `GITHUB_EVENT_NAME` to set up CI telemetry / OpenTelemetry context. It then tries to parse the event payload file at `GITHUB_EVENT_PATH`. The error message phrase `"unknown X-Github-Event in message: schedule"` borrows the HTTP webhook header name (`X-Github-Event`) to describe the event type. Dagger's payload parser knows how to handle standard GitHub webhook events like `push` and `pull_request`, but `schedule` is a workflow *trigger type*, not a webhook event type, so the parser does not recognise it and logs a `WARN`. ### Why it happens The warning appears in runs triggered by `.forgejo/workflows/deploy.yml` (which uses `on: schedule: - cron: '0 * * * *'`). When the workflow runs: 1. Forgejo/Codeberg sets `GITHUB_EVENT_NAME=schedule` in the job environment. 2. The step **Publish Android to Play Store** (jobstep-4) runs `task publish-android`, which calls `dagger call publish-android …`. 3. The Dagger CLI initialises, detects it is running in CI, reads `GITHUB_EVENT_NAME=schedule`, and tries to decode the event payload. 4. The `schedule` type is unknown to Dagger's payload parser → warning is logged. 5. Dagger continues normally; the warning is **non-fatal and the CI job succeeds**. The `.forgejo/workflows/monitor.yml` workflow also uses `on: schedule`, but it only runs `python3 scripts/agent_loop.py monitor` (no Dagger), so it is not affected. ### Impact None. The warning is purely cosmetic noise in the log. The deploy job itself completes successfully. ### How to fix it There are two independent tracks: #### Track A – Upstream Dagger fix (proper long-term fix) The root cause is that the Dagger CLI does not handle the `schedule` event type in its GitHub payload parser. The fix belongs in the Dagger project. **Action**: File a bug / PR against `github.com/dagger/dagger` (the CLI, not the SDK) asking it to treat unknown / non-webhook event types (like `schedule`, `workflow_dispatch`, `repository_dispatch`) gracefully — either by silently skipping the payload parse or by logging at `DEBUG` level instead of `WARN`. No changes to the sharedinbox repo are needed for this track. #### Track B – Suppress at the sharedinbox level (short-term workaround) If the warning is considered distracting, the simplest in-repo fix is to unset `GITHUB_EVENT_NAME` in the dagger-running steps of `deploy.yml`, so Dagger does not attempt CI payload detection: **File**: `.forgejo/workflows/deploy.yml` In each step that invokes a `dagger call …` command (currently **Publish Android to Play Store**, **Build & Deploy APK to server**, **Build & Deploy Linux to server**, **Generate build history and deploy website**), add: ```yaml env: GITHUB_EVENT_NAME: "" # prevent Dagger from attempting schedule-payload parse ``` **Risks**: Unsetting `GITHUB_EVENT_NAME` may affect other Dagger telemetry / tracing metadata that keys off the event type. If Dagger Cloud traces are in use, CI run links might not be annotated with the trigger source. This is minor and acceptable. **Alternative**: Upgrade `dagger.io/dagger` in `ci/go.mod` to a version that handles `schedule` events — check the Dagger changelog for fixes to CI event detection after v0.20.8. ### Summary of files to change | Track | File | Change | |-------|------|--------| | A (upstream) | (Dagger repo, not this repo) | Add `schedule` / unknown-event handling to CLI CI payload parser | | B (workaround) | `.forgejo/workflows/deploy.yml` | Add `GITHUB_EVENT_NAME: ""` env to each dagger-running step | | B (upgrade) | `ci/go.mod` + `ci/go.sum` | Bump `dagger.io/dagger` to latest and re-vendor | ### Recommendation **Do Track A first** — report the bug upstream. In the meantime, Track B (adding `GITHUB_EVENT_NAME: ""`) is a low-risk one-liner in `deploy.yml` and eliminates the log noise immediately. Upgrading Dagger is also worth doing independently of this issue.
guettlibot commented 2026-05-28 04:23:02 +00:00 (Migrated from codeberg.org)

Planning complete. To resume this session:

claude --resume 8abe79b9-a001-4ef7-b433-290ec04ae107 --dangerously-skip-permissions
Planning complete. To resume this session: ``` claude --resume 8abe79b9-a001-4ef7-b433-290ec04ae107 --dangerously-skip-permissions ```
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: guettli/sharedinbox#318