[Investigate] notify-triagers workflow is intermittently failing

[princerajpoot20]

The notify-triagers workflow is behaving intermittently.

• In some runs, the workflow fails. FYR: https://github.com/asyncapi/website/actions/runs/20653553533/job/59327722596
• In other runs, it passes but still does not notify the triagers FYR: https://github.com/asyncapi/website/actions/runs/20662472045/job/59327968051?pr=4785

FYI: #4785 (comment)

[sammy200-ui]

should i look into this @princerajpoot20

[princerajpoot20]

@sammy200-ui yeah..go ahead

[sammy200-ui]

@princerajpoot20 some founding here ... so the workflow might be failing at the Count changed files step because of this current checkout

repository: ${{ github.event.pull_request.head.repo.full_name }}
ref: ${{ github.event.pull_request.head.sha }}

then tries to run:
git diff --name-only ${{ github.event.pull_request.base.sha }} ${{ github.event.pull_request.head.sha }}

the possible problem here would be the base.sha from website may not exist in the fork's git history if the fork hasn't synced recently , that might be causing exit code 128

another issue here might be that when the workflow passes, it still doesn't add reviewers because of this condition:
if: ${{ steps.check-merge-branch.outputs.isMergeCommit == 'false' && ... }}

When a maintainer syncs the PR branch with master (creating a merge commit like "Merge branch 'master' into..."), isMergeCommit becomes true and both reviewer steps are skipped.

[sammy200-ui]

we could checkout with the base repository instead of the fork

[KariraLakshya]

@princerajpoot20 Can i work on this PR??

[Sourya07]

@KariraLakshya, could you please look into the issue and share your findings? A maintainer can then assign it to you.

[KariraLakshya]

@princerajpoot20
I've dug into the intermittent failures (Exit Code 128) and the silent skips in this workflow, and I believe I've found the root causes.

1. The Crash (Exit Code 128)
The workflow is currently crashing because of the default shallow clone behavior. When the runner tries to calculate the diff, it often fails to find the target commit (base SHA) in the limited history—especially when dealing with forks that aren't perfectly synced with upstream.
Proposed Fix: We need to configure the checkout step to fetch the full git history (depth 0) and explicitly fetch the upstream base ref to guarantee git diff always has a valid target to compare against.

2. The Silent Failure
I also noticed that valid PR updates are being skipped. The current logic checks if a commit is a "Merge Commit" and aborts if true. This means if a user updates their branch by syncing with master (which creates a merge commit), the triagers are never notified.
Proposed Fix: We should remove or relax the merge-commit check so that all valid updates trigger a notification, ensuring no PRs slip through the cracks.

I have a working solution for this locally. Let me know if you'd like me to raise a PR!

[sammy200-ui]

@KariraLakshya I dont think the root cause is shallow cloning , the workflow already has fetch depth . The actual problem might be that it checks out the fork's repository , but then tries to git diff against base.sha which is from the upstream repository.

[SHUBHANSHU602]

I think @sammy200-ui is pointing to the core issue.

In pull_request_target, the workflow checks out the fork repo, but base.sha belongs to the upstream repo, so that commit may not exist locally. This explains the intermittent “bad object” failures even with sufficient fetch depth.

A safer fix would be to diff refs (origin/${{ github.base_ref }}...HEAD) or explicitly fetch the base ref, rather than relying on SHAs.
If this approach (diffing refs instead of SHAs) makes sense to you, I’d be happy to prepare a PR for it. Let me know.

[KariraLakshya]

@sammy200-ui If that's the case then we can work on the issue.

[sammy200-ui]

@KariraLakshya should be confirmed with @princerajpoot20