Summary

check_workflow_timestamp_api.cjs fails with 404 when a reusable workflow is invoked cross-repo via workflow_call. The fix in #23808 (v0.65.4) resolved this for org ruleset invocations but not for workflow_call.

Root cause

The script parses GITHUB_WORKFLOW_REF to determine the source repo for fetching the lock file. For workflow_call, this env var points to the caller's workflow, not the callee's reusable workflow:

• GITHUB_WORKFLOW_REF = strawgate/memagent/.github/workflows/<caller>.yml@refs/heads/main
• Script resolves source repo as strawgate/memagent
• Fetches .github/workflows/gh-aw-pr-review.lock.yml from strawgate/memagent → 404
• Lock file actually lives in elastic/ai-github-actions

The github.workflow_ref context property has special handling for reusable workflows ("always refers to the reusable workflow"), but the GITHUB_WORKFLOW_REF environment variable reflects the top-level initiating workflow.

Repro

1. Repo A (elastic/ai-github-actions) has a reusable workflow compiled with gh-aw
2. Repo B (strawgate/memagent) calls it via workflow_call
3. Activation job fails at "Check workflow file timestamps":

Could not fetch content for .github/workflows/gh-aw-pr-review.lock.yml: Not Found
Could not compare frontmatter hashes - assuming lock file is outdated
Error: ERR_CONFIG: Lock file '.github/workflows/gh-aw-pr-review.lock.yml' integrity check failed!

Run: https://github.com/strawgate/memagent/actions/runs/23859476712/job/69561948863

Suggested fix

Use context.payload.workflow_ref or pass the callee repo explicitly via a compiler-injected env var (e.g. GH_AW_SOURCE_REPO) on the check step, since the compiler knows the source repo at compile time.

Workaround

on.stale-check: false in frontmatter disables the check entirely (added in #23808).