You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some code commits referencing CXFLW-516 have added a second ERROR log output of the stack trace to various parts of the code. While these are good for unexpected errors, it is not good for valid errors. I can't enumerate them all, but the particular example is when there is a 404 error trying to retrieve the config-as-code file.
Config-as-code is not a required file in a repository and is not a failure scenario. Logging stack traces for a non-failure scenario is functionally useless. Logging stack traces for HTTP 4xx errors is likely also not useful since it is understood why the error occurred. Troubleshooting would likely be more focused on the wire trace for 4xx errors, not the stack trace.
Previously it would report the response code and move on without failure of the scan. The scan can fail for other reasons (such as an invalid team due to no config-as-code), but that failure is in a different part of the logic.
Now, the log is spammed with a large stack trace each and every time config-as-code is not found in a repo. Example:
2023-02-23 00:00:38.364 ERROR 4192 --- [nio-9000-exec-3] c.c.f.s.BitBucketService [wOBOAykF] : Error occurred while loading CxConfig From Bitbucket. http error 404 NOT_FOUND
2023-02-23 00:00:38.365 ERROR 4192 --- [nio-9000-exec-3] c.c.f.s.BitBucketService [wOBOAykF] : org.springframework.web.client.HttpClientErrorException$NotFound: 404 : "{"errors":[{"context":null,"message":"The path \".cxflow\" does not exist at revision \"190765ac7669a8ae295e89c7d98780132d91eeb6\"","exceptionName":"com.atlassian.bitbucket.content.NoSuchPathException"}]}"
at org.springframework.web.client.HttpClientErrorException.create(HttpClientErrorException.java:113)
at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:168)
at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:122)
at org.springframework.web.client.ResponseErrorHandler.handleError(ResponseErrorHandler.java:63)
at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:819)
at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:777)
at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:732)
at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:612)
at com.checkmarx.flow.service.BitBucketService.loadCxConfigFromBitbucket(BitBucketService.java:526)
at com.checkmarx.flow.service.BitBucketService.getCxConfigOverride(BitBucketService.java:462)
at com.checkmarx.flow.handlers.bitbucket.server.BitbucketServerEventHandler.checkForConfigAsCode(BitbucketServerEventHandler.java:52)
at com.checkmarx.flow.handlers.bitbucket.server.BitbucketServerMergeHandler.execute(BitbucketServerMergeHandler.java:96)
at com.checkmarx.flow.controller.bitbucket.server.postwebhook.PostWebhookController.doMerge(PostWebhookController.java:278)
at com.checkmarx.flow.controller.bitbucket.server.postwebhook.PostWebhookController.prSourceBranchUpdateRequest(PostWebhookController.java:224)
at jdk.internal.reflect.GeneratedMethodAccessor142.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:205)
at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:150)
at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:117)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:895)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:808)
at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1067)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:963)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:909)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:696)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:779)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at com.checkmarx.flow.filter.CaseTransformingFilter.doFilterInternal(CaseTransformingFilter.java:30)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:100)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:93)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.springframework.boot.actuate.metrics.web.servlet.WebMvcMetricsFilter.doFilterInternal(WebMvcMetricsFilter.java:96)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:201)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at com.checkmarx.flow.filter.SecurityFilter.doFilter(SecurityFilter.java:41)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:177)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:360)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:399)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:891)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1784)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
Expected Behavior
Report the HTTP error code for valid failures without blasting a large wall of useless text into the log.
Actual Behavior
Reports lots of useless data in the log.
Reproduction
Scan a repo that doesn't have a config-as-code file in every supported SCM.
I confirmed this happens for BitBucket and ADO, but I did not look further.
There are likely other places where a valid failure emits a stack trace into the log.
Environment Details
CxFlow 1.6.39 with webhook mode.
The text was updated successfully, but these errors were encountered:
Description
Some code commits referencing
CXFLW-516
have added a second ERROR log output of the stack trace to various parts of the code. While these are good for unexpected errors, it is not good for valid errors. I can't enumerate them all, but the particular example is when there is a 404 error trying to retrieve the config-as-code file.Config-as-code is not a required file in a repository and is not a failure scenario. Logging stack traces for a non-failure scenario is functionally useless. Logging stack traces for HTTP 4xx errors is likely also not useful since it is understood why the error occurred. Troubleshooting would likely be more focused on the wire trace for 4xx errors, not the stack trace.
Previously it would report the response code and move on without failure of the scan. The scan can fail for other reasons (such as an invalid team due to no config-as-code), but that failure is in a different part of the logic.
Now, the log is spammed with a large stack trace each and every time config-as-code is not found in a repo. Example:
Expected Behavior
Report the HTTP error code for valid failures without blasting a large wall of useless text into the log.
Actual Behavior
Reports lots of useless data in the log.
Reproduction
Scan a repo that doesn't have a config-as-code file in every supported SCM.
I confirmed this happens for BitBucket and ADO, but I did not look further.
There are likely other places where a valid failure emits a stack trace into the log.
Environment Details
CxFlow 1.6.39 with webhook mode.
The text was updated successfully, but these errors were encountered: