NullPointerException when pull request is created.

[doughanks]

When I create a pull request, a NullPointerException is thrown.

I saw the other NPE issue, but my configuration has the 'Skip SSL Certification Validation' checkbox checked, so it may not be the same issue.

Based on the stack trace, this may be related to the 'Committers to ignore' option. This field is blank in my configuration.

Here is the error from the Stash log.

--snip--

2013-10-17 09:18:03,854 ERROR [AtlassianEvent::pool-3-thread-1] ---[identity removed=--- SSH - git-receive-pack '~dhanks/dhanks-cfmgt-filenameparsing.git' c.a.e.i.AsynchronousAbleEventDispatcher There was an exception thrown trying to dispatch event 'com.atlassian.stash.event.RepositoryPushEvent[source=com.atlassian.stash.internal.hook.PostReceiveEventHook@644d254e]' from the invoker 'SingleParameterMethodListenerInvoker{method=public void com.nerdwin15.stash.webhook.RepositoryChangeListener.onRefsChangedEvent(com.atlassian.stash.event.RepositoryRefsChangedEvent), listener=com.nerdwin15.stash.webhook.RepositoryChangeListener@5e123c18}'. java.lang.RuntimeException: java.lang.NullPointerException at com.atlassian.event.internal.SingleParameterMethodListenerInvoker.invoke(SingleParameterMethodListenerInvoker.java:50) ~[atlassian-event-2.3.0.jar:na] at com.atlassian.event.internal.AsynchronousAbleEventDispatcher$2.run(AsynchronousAbleEventDispatcher.java:66) ~[atlassian-event-2.3.0.jar:na] at com.atlassian.sal.core.executor.ThreadLocalDelegateRunnable.run(ThreadLocalDelegateRunnable.java:38) ~[sal-core-2.10.3.jar:na] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ~[na:1.7.0_25] at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25] Caused by: java.lang.NullPointerException: null at com.nerdwin15.stash.webhook.service.eligibility.IgnoreCommittersEligibilityFilter.shouldDeliverNotification(IgnoreCommittersEligibilityFilter.java:41) ~[na:na] at com.nerdwin15.stash.webhook.service.eligibility.ConcreteEligibilityFilterChain.shouldDeliverNotification(ConcreteEligibilityFilterChain.java:27) ~[na:na] at com.nerdwin15.stash.webhook.RepositoryChangeListener.onRefsChangedEvent(RepositoryChangeListener.java:34) ~[na:na] at sun.reflect.GeneratedMethodAccessor5099.invoke(Unknown Source) ~[na:na] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_25] at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_25] at com.atlassian.event.internal.SingleParameterMethodListenerInvoker.invoke(SingleParameterMethodListenerInvoker.java:36) ~[atlassian-event-2.3.0.jar:na] ... 5 common frames omitted

---end snip---

Thanks, Doug

[mikesir87]

Hi Doug! I just released an update to the plugin (v. 2.0.1) last night that should determine the webhook should fail before the NPE gets thrown.

But, it's interesting that it is throwing because it's saying that the Settings is null, which seems to indicate that the webhook might be disabled. Can you confirm that the webhook is enabled and configured for the repository you're making the pull request on? From what you've said, it shouldn't be null.

[doughanks]

Yes, the hook is showing Enabled on the 'destination' repository. It is not enabled on the 'source' repository. I was viewing the source repository when I created the pull request.

I just pulled down your update. Thanks for that fix. When I initiate another pull request, I'll see if anything different happens and update here.

[mikesir87]

That could be what was triggering it then, as you're using two different repositories. When sending a pull request from different repositories, only the source repo fires a repository change event (what the plugin listens to). From there, it goes through all the "Should we actually fire it" logic. There was a bug in it that generated a NPE for repositories that had the webhook disabled. The end result would be that the webhook wouldn't fire, so the end result didn't change, but it still fills the log. The update resolves that.

When it comes to pull requests, Stash does not trigger a repository change event for the receiving repository. Once the merge has occurred, another repo change event is published and we trigger a build. So... yeah... it's kinda stinky that you don't know if a pull request may break your build until after the merge, but that might be consideration for future work (if it's even possible right now).

[doughanks]

Thanks for the update. We have a Jenkins job set up to build on the origin/pull-requests//from and origin/pull-requests//merge* branches. It would have been nice to have them triggered when a new pull request or an update to a pull request occurs so that our build server doesn't have to do so much polling.

I'll just set these back to poll more frequently.

BTW, the update solved the non-admin user issue. Thanks for the quick response.

[mikesir87]

Closing as initial issue has been resolved.

There is another issue (Issue #38) that is tracking the development of the pull request functionality.