Executions should return msg and any query params

[Matthew Vaughn]

For sake of reproducibility, executions should report the message and any query parameters that were sent. The message (but not query params) are reported when the message is posted, but not the query params, and neither are apparently available when one polls an actor's /executions endpoint.

[Rion Dooley]

This should all be available from the actor’s logs. IMHO, it seems like we might want to capture the following for each actor execution: * stdout * stderr * exit code * environment I’m pretty sure persisting that info would be a challenging decision operationally, but what might be useful is to support a redirection options in the execution request so any of that content can be captured and consumed as needed. Use case: I want to invoke an actor in response to a web request and respond to the request through an asynchronous callback from the actor. To do this, I invoke the actor with a parameter to stream the stdout and stderr to a web socket channel. The request handler subscribes to the channel and echoes the response from the actor back to the caller. Use case: I want to apply a lightweight transform against the contents of some data. The data could be passed into the execution environment, presaged, or subscribed to. Upon completion, the result should be passed on as the input context to another execution, effectively piping input to output. In situation where the data is too large to push into an environment variable, having the flexibility to specify a location on disk, cache, socket, or stdout would give us the flexibility to scale to different use cases. — Rion On Feb 24, 2017, at 5:16 PM, Matthew Vaughn <[e-mail]<mailto:[e-mail]>> wrote: For sake of reproducibility, executions should report the message and any query parameters that were sent. The message (but not query params) are reported when the message is posted, but not the query params, and neither are apparently available when one polls an actor's /executions endpoint. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#19>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAv7MnG0w-sUTrw4XdO48rZCclPfz5xfks5rf2S4gaJpZM4MLyJi>.