Random HTTP 500 errors while updating design time artifacts: error while trying to invoke the method javax.servlet.http.HttpSession.getAttribute(java.lang.String) of a null object loaded from local variable 'httpSession'

[micsafi]

Flashpipe fails randomly to update design time artefacts, receiving HTTP 500 error from the CPI APIs. So far I have been able to resolve this by re-running the deployment steps in the pipeline, but it might take 2-3 rerun attempts to get the artefacts deployed.

When the issue occurs, it will fail on all CPI artefacts, not any particular artefact.

Using flashpipe image version engswee/flashpipe:2.6.0.

[INFO] IFlow design will be updated in CPI tenant
--
374 | [INFO] Executing command: java -classpath /usr/share/maven/ref/repository/io/github/engswee/flashpipe/2.6.0/flashpipe-2.6.0.jar:/usr/share/maven/ref/repository/org/codehaus/groovy/groovy-all/2.4.21/groovy-all-2.4.21.jar:/usr/share/maven/ref/repository/org/apache/httpcomponents/core5/httpcore5/5.0.4/httpcore5-5.0.4.jar:/usr/share/maven/ref/repository/org/apache/httpcomponents/client5/httpclient5/5.0.4/httpclient5-5.0.4.jar:/usr/share/maven/ref/repository/commons-codec/commons-codec/1.15/commons-codec-1.15.jar:/usr/share/maven/ref/repository/org/slf4j/slf4j-api/1.7.25/slf4j-api-1.7.25.jar:/usr/share/maven/ref/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.17.1/log4j-slf4j-impl-2.17.1.jar:/usr/share/maven/ref/repository/org/apache/logging/log4j/log4j-api/2.17.1/log4j-api-2.17.1.jar:/usr/share/maven/ref/repository/org/apache/logging/log4j/log4j-core/2.17.1/log4j-core-2.17.1.jar:/usr/share/maven/ref/repository/org/zeroturnaround/zt-zip/1.14/zt-zip-1.14.jar io.github.engswee.flashpipe.cpi.exec.UpdateDesignTimeArtifact
375 | [INFO] Using Basic Authentication for https://oauthasservices-xxxx.hana.ondemand.com:443
376 | [INFO] Using OAuth 2.0 Authentication for https://xxxxx-tmn.hci.eu1.hana.ondemand.com:443
377 | [INFO] Update design time artifact xxx-yyy-zzz
378 | [ERROR] 🛑 Response body = {"error":{"code":"Internal Server Error","message":{"lang":"en","value":"while trying to invoke the method javax.servlet.http.HttpSession.getAttribute(java.lang.String) of a null object loaded from local variable 'httpSession'"}}}
379 | Exception in thread "main" io.github.engswee.flashpipe.http.HTTPExecuterException: Update design time artifact call failed with response code = 500
380 | at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
381 | at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
382 | at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
383 | at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
384 | at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
385 | at org.codehaus.groovy.reflection.CachedConstructor.doConstructorInvoke(CachedConstructor.java:77)
386 | at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrap.callConstructor(ConstructorSite.java:84)
387 | at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
388 | at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:238)
389 | at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:250)
390 | at io.github.engswee.flashpipe.http.HTTPExecuter.logError(HTTPExecuter.groovy:42)
391 | at io.github.engswee.flashpipe.http.HTTPExecuter$logError$1.call(Unknown Source)
392 | at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
393 | at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
394 | at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:128)
395 | at io.github.engswee.flashpipe.cpi.api.DesignTimeArtifact.updateArtifact(DesignTimeArtifact.groovy:102)
396 | at io.github.engswee.flashpipe.cpi.api.DesignTimeArtifact.update(DesignTimeArtifact.groovy:53)
397 | at io.github.engswee.flashpipe.cpi.api.DesignTimeArtifact$update.call(Unknown Source)
398 | at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
399 | at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
400 | at io.github.engswee.flashpipe.cpi.exec.UpdateDesignTimeArtifact.execute(UpdateDesignTimeArtifact.groovy:64)
401 | at io.github.engswee.flashpipe.cpi.exec.UpdateDesignTimeArtifact$execute$0.call(Unknown Source)
402 | at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
403 | at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
404 | at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
405 | at io.github.engswee.flashpipe.cpi.exec.UpdateDesignTimeArtifact.main(UpdateDesignTimeArtifact.groovy:27)
406 | [ERROR] 🛑 Execution of java command failed
407 |  
408 | [Container] 2022/09/22 08:47:25 Command did not exit successfully bash /usr/bin/update_designtime_artifact.sh exit status 1

[engswee]

Hi @micsafi

If the errors are from the server and rerunning the pipeline works, then the issue is with the CPI tenant rather than with FlashPipe. I don't really see anything to be done here since it doesn't sound like it can be consistently reproduced. If you have any ideas though, I'm happy to hear them out.

[micsafi]

Hi @engswee,

1. Is the error common in your opinion and have you seen it before with the tenants that you are working with?
2. If the error is common, would it make sense to build an automatic wait/retry functionality in the Flashpipe scripts that would be configurable? Naturally this can be done in the pipeline level, but might be usable for others as well.
3. In your opinion, is SAP Support responsive when reporting issues related to Tenant Managent APIs (which Flashpipe relies on)?

[engswee]

1 - No, I've not seen this error before. Such random errors only ever occur once in a blue moon on the tenants I work with 3 - I can't tell really. I haven't had encountered any issues with the TMN APIs which persist over an extended period of time. It's only a random error every now and then