Record Invocation Parameters for Activations

[jthomas]

This is a feature request.

Activations logs for Action invocations record the output from the Action but not the input parameters. Recording these parameters would help developers diagnose and reproduce issues in with services in production.

The parameters for the trigger invocations are currently stored as the result field in the response property. This property contains the Action result for Action invocations.

It would be nice to have a parameters field with these values that is consistent for triggers and actions.

[rabbah]

This is related to #512 where we might drop activation records for triggers altogether (and we're entertaining dropping the payload content for triggers already).

[rabbah]

One way to do this: create an echo action and sequence it with your existing actions.

[mbehrendt]

when dropping log information -- how do we continue to provide enough information to developers for problem determination? i think we should err on the side of providing more than less information...

[rabbah]

When dropping log information? There was no suggestion to drop log information. The issue I referenced above is to trade off trigger activation records for ones where user explicitly logs trigger payloads if they want to persist them.

The feature request in this issue is to record the invocation parameters in the activation record. Instead of doing that I suggested if one want to do that they can sequence an action to record activation parameters either by logging them or as the result of an echo action.

In other words the system already provides a way for the user to record incoming parameters.

[mbehrendt]

as you said you can work around it with sequences, but i as a dev wouldn't want to do this all the time. would be much nicer if that information would just be persisted without me having to do anything.

wrt 'dropping' -- i referred to your stmt "where we might drop activation records for triggers altogether (and we're entertaining dropping the payload content for triggers already)."

[rabbah]

Let's clarify terminology. Logs are user generated. The activation record contains the user generated logs in addition to other properties.

So we're discussing whether the system should automatically log input parameters to all invocations. We can't store these in user generated logs because they would take away from the quota. If the user wants to log them it's simple enough to do from their code. If the code is not accessible to the user the alternative is a sequence - an openwhisk strength and it's quite convenient to create new sequences.

So on one hand we leverage the strengths of the system for the case where user wants to log parameters. On the other we pay the extra overhead of recording all parameters for all activations in the system.

Without establishing a retention policy on the activation records, and without evidence that the common case is to want the parameters logged vs not, I posit the system already provides the desired functionality.

[mbehrendt]

ah -- you're suggestion that developers should just do a console.log(<parameters> in their code if they want to have parameters logged? yeah, i think that would be fine, at least in the short-term.

besides that, i think there is a retention policy needed in any case.

[jthomas]

Manually logging the parameters is a sensible solution in the short-term. I still think the system recording the invocation parameters somewhere would be a "nice to have" feature. People often don't set up logging until after something goes wrong.

Having this feature would also ease having tools that automated analysis or replay of invocations. It's more difficult to implement these tools if the parameters are in user logs, as opposed to a structured API response field.

[rabbah]

Using an echo action to enable repay debugging makes the cost explicit for the user and doesn't force the system to log activations where in the common case, are not needed. I am closing as won't fix.