Include-commit-authors (config) produces no author output — no trace of author/graphql logic in debug logs

Summary

With include-commit-authors: true set in release-please-config.json, no author attribution ever appears in generated changelog entries or release-PR bodies — not (@username), not a fallback name, nothing. Full ACTIONS_STEP_DEBUG-level logs from release-please-action@v5 show zero trace of any author/GraphQL-related processing at all, despite #2628's description stating a GraphQL query and DefaultChangelogNotes changes were added for this.

Environment

• release-please version (per action log): 17.6.0
• Action: googleapis/release-please-action@v5 (resolved SHA 45996ed1f6d02564a971a2fa1b5860e934307cf7 at time of testing)
• Repo: public, single-package (release-type: simple, path .)
• No release-type (or any other config-shadowing input) passed as an action with: input — confirmed custom changelog-sections entries (e.g. a custom cont type) render correctly, proving the config file itself is being read successfully.

release-please-config.json

```json { "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json", "include-commit-authors": true, "packages": { ".": { "release-type": "simple", "changelog-sections": [ { "type": "feat", "section": "Features", "hidden": false }, { "type": "fix", "section": "Bug Fixes", "hidden": false }, { "type": "cont", "section": "Continuations", "hidden": false }, { "type": "perf", "section": "Performance Improvements", "hidden": false }, { "type": "refactor", "section": "Code Refactoring", "hidden": false }, { "type": "docs", "section": "Documentation", "hidden": false }, { "type": "other", "section": "Other", "hidden": false }, { "type": "revert", "section": "Reverts", "hidden": false } ] } } } ```

.github/workflows/release-please.yml

```yaml name: release-please

on: push: branches: [ main ]

permissions: contents: write pull-requests: write

jobs: release-please: runs-on: ubuntu-latest steps: - uses: googleapis/release-please-action@v5 ```

Steps to reproduce

1. Set include-commit-authors: true at the top level of release-please-config.json, merge to main.
2. Push several ordinary fix:/other:-titled commits authored by a real, resolvable GitHub account (verified via github.com/<owner>/<repo>/commit/<sha> — the commit's avatar/username cleanly links to the account, so GraphQL author.user resolution should succeed).
3. Let release-please-action build/update the standing release PR.
4. Inspect the release PR body.

Expected behavior

Per #2628's documented behavior, each changelog line should show (@username) (or a name fallback).

Actual behavior

No author info appears anywhere in the release PR body or published changelog, across multiple consecutive releases.

Debug log (ACTIONS_STEP_DEBUG=true)

Full step output attached below. Note the complete absence of any log line referencing "author," "graphql," or "login" — it goes straight from commit-collection to the finished PR-diff decision with no visible author-processing step in between:

``` ✔ Splitting 4 commits by path ✔ Building candidate release pull request for path: . ❯ type: simple ❯ targetBranch: main ❯ commits: 4 ✔ Considering: 4 commits ❯ component: ❯ pull request title pattern: undefined ❯ componentNoSpace: undefined ✔ Looking for open release pull requests ✔ found 1 open release pull requests. ✔ Looking for snoozed release pull requests ✔ found 0 snoozed release pull requests. ✔ PR https://github.com/.../pull/45 remained the same ```

(Full log available on request — happy to attach the complete run.)

What I've already ruled out

• Config not being read → disproven (custom changelog-sections types render correctly)
• release-type passed as action input shadowing config file (known coupling issue) → not applicable, no with: block at all in workflow
• Commit author email unresolvable to a GitHub account → disproven (GitHub's own UI cleanly resolves the test commit to the account)
• Bot-authored commits (Bot vs User GraphQL type) → not applicable, test commits are human-authored
• Token permissions (default GITHUB_TOKEN vs a fine-grained PAT with contents/pull-requests read-write) → tested both, no difference

Related

• #2628 (the feature PR — merged, confirms intended behavior)
• #2760 (schema gap — confirmed cosmetic, not the cause here)