CreateEventWithHTTPClient nil pointer dereference

[blockpane]

Line 52 of event.go

has the following:

	resp, err := client.Do(req)
	if err != nil {
		return &EventResponse{HttpStatus: resp.StatusCode}, err
	}

In the case of an actual error, it is very likely that resp is nil, and will result in a runtime panic. For example:

standby_1  | panic: runtime error: invalid memory address or nil pointer dereference
standby_1  | [signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x673028]
standby_1  |
standby_1  | goroutine 1 [running]:
standby_1  | github.com/PagerDuty/go-pagerduty.CreateEventWithHTTPClient(0x7ffe1cd47f17, 0x20, 0x7b3de3, 0x7, 0x7ffe1cd47eed, 0xc, 0xc0004d6340, 0x34, 0x0, 0x0, ...)
standby_1  | 	/Users/tag/pkg/mod/github.com/!pager!duty/go-pagerduty@v1.3.0/event.go:52 +0x588
standby_1  | github.com/PagerDuty/go-pagerduty.CreateEvent(...)
standby_1  | 	/Users/tag/pkg/mod/github.com/!pager!duty/go-pagerduty@v1.3.0/event.go:36
standby_1  | main.notifyPagerduty(0xc0004bfa00, 0x7bdff3, 0x20, 0x7ffe1cd47eed, 0xc, 0x7ffe1cd47f17, 0x20, 0x0, 0x0)

The V2 client handles this properly and returns nil. (Also note: I meant to use the V2 API in the first place, so this doesn't actually affect me.)

Thanks for the handy library.

[theckman]

@blockpane good lookin' out. Would you be able to raise a PR? If not I can get to it this weekend.

If you raise the PR I can review it + merge it; otherwise I'm blocked on a PagerDuty employee giving me a review since I don't have the power to merge my own PRs.

In short, I think making this a wrapped error (fmt.Errorf("failed to action request: %w", err)) would be the right fix.

[blockpane]

Absolutely, but I don't see a develop branch, where should I send the PR? master?

[blockpane]

Assuming you take Friday nights off, like I should, lol, I assumed a PR vs master, if inappropriate we can revisit next week, cheers, and thanks again for providing a useful free library :)

[theckman]

This will be included in v1.4.0 when it's eventually release. If you're actively running into this on v1.3.0, please file an issue and we can work on backporting the fix to a v1.3.1.