github-migration icon indicating copy to clipboard operation
github-migration copied to clipboard

avatar_url error on npm run createComments

Open krtx1 opened this issue 5 years ago • 3 comments

Heya :)

Have a specific issue on avatar_url on createComments:

[root@ip-10-202-197-7 github-migration]# npm run createComments [email protected] createComments /opt/github-migration node ./createComments.js Comments to process: 96 ETA: 02m 52s Comment 18 already processed ETA: 02m 51s Adding comment 10 to https://api.github.com/repos/dummy_test/pulls/1/comments TypeError: Cannot read property 'avatar_url' of null at createMessage (/opt/github-migration/createMessage.js:44:35) at createPullRequestComment (/opt/github-migration/createComments.js:158:18) at async createComment (/opt/github-migration/createComments.js:90:5) at async main (/opt/github-migration/createComments.js:289:5)

The avatarUrl on the destination is the default: avatarUrl: 'https://avatars0.githubusercontent.com/u/{id}?s=40&v=4',

How can I debug this further?

krtx1 avatar May 21 '20 04:05 krtx1

Looking in the pull-comments.json, it is when the user is defined as null:

"user": null,

krtx1 avatar May 21 '20 05:05 krtx1

@krtx1 Sorry about that. I'm open to pull requests.

It looks like there needs to be special handling when issue.user is undefined. The createMessage should be refactored a bit to handle a null user while still giving useful information.

I am curious though, what does it mean to have a comment that wasn't made by a user? Maybe the user is deleted? This wasn't a use-case I anticipated.

NicholasBoll avatar May 21 '20 15:05 NicholasBoll

@NicholasBoll thanks for the reply.

If will open a PR if I dig through the code and understand the fix well enough.

One thing that I forgot to mention is that on the specific repository that I was testing this on, it had an LDAP integration, and while the user existed on the comment, the comment was made by an internal user (on GitHub's internal managed DB of users) before the LDAP integration was switched on.

And my assumption is that when it was interacting with the GitHub API, when it tried to look up the user is got nothing back from LDAP, hence the null, and also over the fact that the auth is LDAP, it cannot just override that and go, first lookup internal users, then LDAP (or vice versa); the auth is the auth, single place to lookup, however I don't know the GitHub API well enough to confirm if it is possible to query LDAP and then internal users, etc.

So my fix was just to edit the pull-comments.json manually and search and replace the "user": null block with something valid from LDAP, like so:

 "user": {
  "login": "johndoe",
  "id": 105,
  "avatar_url": "https://dummyorg.net/avatars/u/105?",
  "gravatar_id": "",
  "url": "https://dummyorg.net/api/v3/users/johndoe",
  "html_url": "https://dummyorg.net/johndoe",
  "followers_url": "https://dummyorg.net/api/v3/users/johndoe/followers",
  "following_url": "https://dummyorg.net/api/v3/users/johndoe/following{/other_user}",
  "gists_url": "https://dummyorg.net/api/v3/users/johndoe/gists{/gist_id}",
  "starred_url": "https://dummyorg.net/api/v3/users/johndoe/starred{/owner}{/repo}",
  "subscriptions_url": "https://dummyorg.net/api/v3/users/johndoe/subscriptions",
  "organizations_url": "https://dummyorg.net/api/v3/users/johndoe/orgs",
  "repos_url": "https://dummyorg.net/api/v3/users/johndoe/repos",
  "events_url": "https://dummyorg.net/api/v3/users/johndoe/events{/privacy}",
  "received_events_url": "https://dummyorg.net/api/v3/users/johndoe/received_events",
  "type": "User",
  "site_admin": false,
  "ldap_dn": "CN=John Doe,OU=City,OU=Country,OU=Users,DC=dummyorg,DC=net"
},

krtx1 avatar May 26 '20 05:05 krtx1