openwhisk-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [openwhisk] tysonnorris commented on a change in pull request #4754: Mcdan/truncate keep running
Date Mon, 25 Nov 2019 20:00:32 GMT
tysonnorris commented on a change in pull request #4754: Mcdan/truncate keep running
URL: https://github.com/apache/openwhisk/pull/4754#discussion_r350392400
 
 

 ##########
 File path: common/scala/src/main/scala/org/apache/openwhisk/core/entity/ActivationResult.scala
 ##########
 @@ -62,40 +63,47 @@ protected[core] object ActivationResponse extends DefaultJsonProtocol
{
   val ApplicationError = 1 // action ran but there was an error and it was handled
   val DeveloperError = 2 // action ran but failed to handle an error, or action did not run
and failed to initialize
   val WhiskError = 3 // internal system error
+  val Truncated = 4 // action ran correctly, but returned a response that was too large
 
 Review comment:
   Currently in https://github.com/apache/openwhisk/blob/ce6a5b7611c46f7d8a528c9987cfb9e9d50ade44/common/scala/src/main/scala/org/apache/openwhisk/core/entity/ActivationResult.scala#L208
there is precisely one path that results in ApplicationError (where developer returns an `{error:"message"}`
in result), and I am suggesting we change this method to include one additional case here,
where truncation results in ApplicationError as well, with the difference that we force the
error message to be the truncation message. The result is that all other code remains the
same, but the container is left in place to continue processing. You might wonder when the
result of returning an error message in result AND truncating the result - but we also don't
handle that case today (truncation error takes precedent). 
   
   There was a separate problem with truncation, in that we currently truncate to the "max
size string", which is mostly useless afaik, since this is often (always?) json or some other
content that cannot be parsed at all. I wouldn't mind seeing the truncation amount limited
to either 0 or 512 bytes (or something small) so that the extra useless content is not contributing
to db bloat - since the truncated content is arguably useless, even for debugging purposes.
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

Mime
View raw message