JAORMX opened a new pull request, #8894:
URL: https://github.com/apache/incubator-devlake/pull/8894
So, you point DevLake at a public repo, let it sync, and then go looking for
who filed a given issue:
```sql
SELECT i.url, i.creator_id, i.creator_name, a.user_name
FROM issues i
LEFT JOIN accounts a ON a.id = i.creator_id
WHERE i.url = 'https://github.com/stacklok/toolhive/issues/4297';
```
`creator_id` is set, `creator_name` says `milichev`, and `a.user_name` comes
back NULL. The login is sitting right there one column over, but the join to
`accounts` finds nothing. Anyone who only filed an issue, or opened a PR
without committing to the repo, ends up as an orphan foreign key. Bot filters
that key on `accounts.user_name LIKE '%[bot]'` miss those rows for the same
reason.
Fixes #8886.
### What's actually going on
The issue and PR extractors already write every author into
`_tool_github_repo_accounts`. But `ConvertAccounts` was sourcing the domain
`accounts` table `FROM _tool_github_accounts`, which only gets populated for
users we collected full profiles for... effectively, the people who committed.
So the convertors happily generate `issues.creator_id` and
`pull_requests.author_id` for everyone, while `accounts` only ever sees the
committers. Everybody else orphans.
### The fix
Flip the source. `ConvertAccounts` now reads `FROM
_tool_github_repo_accounts LEFT JOIN _tool_github_accounts`, so every user the
repo references becomes a domain account, enriched with name/email/avatar when
we have the detail and login-only when we don't. The domain id is generated
with the same `didgen` generator the issue/PR convertors use, so the foreign
keys line up exactly.
I also had the PR extractor emit a repo_account for the `merged_by` user,
since `pull_requests.merged_by_id` had the same problem and that user wasn't
being recorded anywhere.
One thing worth calling out: the SQL is kept MySQL and PostgreSQL agnostic
(COALESCE rather than IFNULL, no backtick quoting, values parameterized through
the dal). The join mirrors the one already in `account_org_collector.go`, so
it's a shape we already run on both databases.
### Testing
The e2e fixture didn't actually contain the bug. Every referenced account
already had a profile row, so the test would pass whether or not the fix was
correct. So I added the orphan case from the issue: `milichev`, referenced by
the repo but with no detail row. After conversion they now get a login-only
`accounts` row.
I also added a referential-integrity assertion to `TestAccountDataFlow`:
every account the repo references has to resolve to a domain `accounts` row,
generated with the same id generator the convertors use. To make sure it wasn't
a vacuous test, I reverted just the converter to the old behaviour and
confirmed the test fails on the orphan, then put the fix back.
Full `plugins/github/e2e` suite passes on both MySQL and PostgreSQL.
### Not in this PR
The same shape affects a couple of attribution columns the issue didn't ask
about: plural issue/PR assignees and PR requested reviewers aren't seeded into
`_tool_github_repo_accounts`, so those FKs can still come back unresolved. The
`github_graphql` plugin likely has the same root cause. Happy to follow up on
those separately if there's interest.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
