atlassian-external-hooks
atlassian-external-hooks copied to clipboard
NullPointerException on Pull Request
Hi
Were using 4.8-3 with BB v5.11 and when a PR is created then the user is removed from the authentication, PR is unable to pass merge check.
2019-07-15 05:21:49,564 WARN [http-nio-7991-exec-240] user @10JA8C8x321x59361798x10 usjkii <ip>,0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PROJECT/repos/REPO/pull-requests/8850/merge HTTP/1.1" c.a.s.i.h.r.DefaultRepositoryHookService [PROJECT/REPO[813]] Error calling com.ngs.stash.externalhooks.hook.ExternalMergeCheckHook.preUpdate (com.ngs.stash.externalhooks.external-hooks:external-merge-check-hook) java.lang.NullPointerException: null
Is there a stack trace available for this error?
no, weirdly there isnt any more info in atlassian-bitbucket.log
i have tried to enable debug logs via the following:
curl -u <user> -v -X PUT -d "" -H "Content-Type: application/json" https://bitbucket.viatorsystems.com/rest/api/latest/logs/logger/com.ngs.stash.externalhooks.external-hooks/debug
curl -u <user> -v -X PUT -d "" -H "Content-Type: application/json" https://bitbucket.viatorsystems.com/rest/api/latest/logs/logger/com.ngs.stash.externalhooks.external-hooks.hook/debug
curl -u <user> -v -X PUT -d "" -H "Content-Type: application/json" https://bitbucket.viatorsystems.com/rest/api/latest/logs/logger/com.ngs.stash.externalhooks.external-hooks.hook.ExternalMergeCheckHook.preUpdate/debug
curl -u <user> -v -X PUT -d "" -H "Content-Type: application/json" https://bitbucket.viatorsystems.com/rest/api/latest/logs/logger/com.atlassian.stash.internal.hook.repository/debug
but the above error still shows as WARN with no extra data around it. any suggestions?
That's very strange, because the relevant Bitbucket Server 5.11 code for this is:
} catch (Exception e) {
log.warn("[{}] Error calling {}.preUpdate ({})", request.getRepository(), hook.getClass().getName(),
hookName, e);
return hookFailed(hookName, e);
}
This means the java.lang.NullPointerException: null
in the logs should be immediately followed by its full stack trace. It's all logged at WARN
level, so there should not be any need to adjust log levels.