invalid memory address error when joining github_user on a column with null value

[judell]

repro

create table test (full_name text, author_login text);

insert into test (full_name, author_login) values ('aws/aws_cdk', '0gajun');
insert into test (full_name, author_login) values ('aws/aws_cdk', '14kw');
insert into test (full_name, author_login) values ('aws/aws_cdk', null);

 select
    g.login,
    g.name,
    g.company,
    g.email,
    g.twitter_username
  from
    github_user g
  join
    test t 
  on 
    t.author_login = g.login;

ERROR: runtime error: invalid memory address or nil pointer dereference

background

I was revisiting the scripts at https://github.com/turbot/steampipe-samples/tree/main/github-external-contributor-analysis, and they were failing for the above reason.

I added a null check, e.g. https://github.com/turbot/steampipe-samples/blob/main/github-external-contributor-analysis/aws_cdk.sql#L48, which solved the problem, but had to do a lot of printf-style debugging in the github plugin in order to track it down.

issue-specific discussion

The scripts haven't changed since I wrote them, and I would guess there were always commits with null author_login, so I wondered if this was a regression since v.9 which was the version in play when the scripts first ran successfully. However I tried rolling back to that Steampipe/github-plugin combo and was still hitting the error, so I dunno.

general discussion

It seems generally hard to assemble context around this class of error when it happens. I'm wondering: is that just how it goes with golang (terrible pun, sorry), or are there ways the app could deliver more context when this happens.

[kaidaguerre]

It seems generally hard to assemble context around this class of error when it happens. I'm wondering: is that just how it goes with golang (terrible pun, sorry), or are there ways the app could deliver more context when this happens.

golang seems pretty bad when nil pointer exceptions occur - it can be very hard to trace the issue. I need to dig into best what the best practice approach for this would be

[kaidaguerre]

@judell this is an sdk bug, transferring

[judell]

@kaidaguerre thanks for the quick action here.

golang seems pretty bad when nil pointer exceptions occur - it can be very hard to trace the issue.

I'm a newbie but yeah, that's my observation so far. It's tempting to gripe about ignoring lots of experience with exception handling in other languages, but I'm trying to keep an open mind here, and will be interested to see how this evolves as we go forward.