Discord GitHub Notifications fails for every new stargazer

[Beverly621]

Summary

The Discord GitHub Notifications workflow is currently failing for new stargazers. I noticed this when starring the repository, and the runs immediately before and after mine failed in the same way for other users.

Evidence

• Run #43299 (wunala-bot): https://github.com/unclecode/crawl4ai/actions/runs/34734529387
• Run #43300 (Beverly621): https://github.com/unclecode/crawl4ai/actions/runs/34734586165
• Run #43301 (haoyun18881-beep): https://github.com/unclecode/crawl4ai/actions/runs/34734744872

In run #43300, the notify-discord job fails at:

Send to Google Apps Script (Stars only)

The check annotation reports:

Process completed with exit code 22.

The workflow uses curl -fSs to POST to secrets.GOOGLE_SCRIPT_ENDPOINT, so exit code 22 indicates that the endpoint returned an HTTP error response. Because this first step fails, Set webhook based on event type and Discord Notification are skipped.

Expected behavior

A temporary failure in the optional stargazer-tracking endpoint should ideally not fail the complete workflow or prevent the Discord notification from running.

Possible resolution

There appear to be two possible directions:

1. Fix or redeploy GOOGLE_SCRIPT_ENDPOINT if the current failure is only a service/configuration problem.
2. If spreadsheet tracking is intended to be best-effort, handle this step as a warning (for example with continue-on-error: true) so the Discord notification can still run.

Would the maintainers prefer the second behavior? If so, I would be happy to submit a focused PR targeting develop.

[ntohidi]

Thanks for flagging this, and for the detailed evidence — that made it quick to confirm.

Root cause: secrets.GOOGLE_SCRIPT_ENDPOINT is returning HTTP 403, so curl -fSs exits 22. Because that step has no continue-on-error, the job stops there and the Discord notification never runs. Still reproducing as of today — every watch run is failing, while other event types succeed.

So there are two separate things: the endpoint itself needs to be redeployed on our side, and the workflow shouldn't let an optional tracking step block the notification.

Option 2 is the right call. A PR against develop adding continue-on-error: true to that step would be welcome.

[Beverly621]

Thanks for flagging this, and for the detailed evidence — that made it quick to confirm.

Root cause: secrets.GOOGLE_SCRIPT_ENDPOINT is returning HTTP 403, so curl -fSs exits 22. Because that step has no continue-on-error, the job stops there and the Discord notification never runs. Still reproducing as of today — every watch run is failing, while other event types succeed.

So there are two separate things: the endpoint itself needs to be redeployed on our side, and the workflow shouldn't let an optional tracking step block the notification.

Option 2 is the right call. A PR against develop adding continue-on-error: true to that step would be welcome.

😃 Thanks for the quick fix! Confirmed this matches the proposed graceful-degradation approach.