GitHub App lambda failing on dev, sometimes

Describe the bug Seeing errors in the logs like this:

errorType": "TypeError",
    "errorMessage": "Cannot read property 'full_name' of undefined",
    "stack": [
        "TypeError: Cannot read property 'full_name' of undefined",
        "    at processEvent (/var/task/index.js:121:44)",
        "    at Runtime.exports.handler (/var/task/index.js:174:5)",
        "    at Runtime.handleOnce (/var/runtime/Runtime.js:66:25)"
    ]

Anecdotally, adding repos doesn’t work in dev, although deleting branches does work for existing entities.

Steps to reproduce (I think, just reporting, haven’t tried it)

1. Install GitHub app
2. Add a .dockstore.yml

Additional context Note that dev is on an older version of the lambda, at master branch on commit ca214b6.

Seeing this sort of payload (truncated and redacted):

{
  "action": "added",
  "installation": {
  "repositories_added": [
    {
      "id": xxx,
      "node_id": "yyy",
      "name": "zzz",
      "full_name": "goo/foo",
      "private": false
    }
  ],
  "repositories_removed": [

  ],
 
}

This sort of error in the logs:

{
    "errorType": "TypeError",
    "errorMessage": "Cannot read property 'full_name' of undefined",
    "stack": [
        "TypeError: Cannot read property 'full_name' of undefined",
        "    at processEvent (/var/task/index.js:121:44)",
        "    at Runtime.exports.handler (/var/task/index.js:174:5)",
        "    at Runtime.handleOnce (/var/runtime/Runtime.js:66:25)"
    ]
}

Looks like index.js is looking for body.repository.full_name, but may need to look for body.repositories_added[i].full_name?

┆Issue is synchronized with this Jira Story ┆Issue Type: Story ┆Fix Versions: Dockstore 1.9 ┆Sprint: Sprint 35 Jellyfish ┆Issue Number: DOCK-1338

[coverbeck]

I thought for @garyluu adding workflows via .dockstore.yml wasn’t working on dev. I researched it, found these errors and created a ticket. These particular messages may have been a red herring, but I don’t know if things are working overall.

BTW, latest deploy on dev has this fix.

[agduncan94]

This is not a real error. Pretty much push events return a set of messages, but we only care about a subset. That subset has some expected fields which are not necessarily present in the rest of the set. The lambda didn’t know this, so it was checking for some fields in the rest of the set that are not actually there. The rest of the set is now ignored, so the error message shouldn’t occur anymore.