Including Arguments in Traces
Include Arguments in Stacktrace records the values passed to each function in the trace, not just the function names. It is the most useful diagnostic setting available and the most dangerous.
Where to find it
Architect Panel → Configuration:
- Site Settings — Include Arguments in Stacktrace
Architect Panel → Activity:
- Error Log — where the captured arguments are stored
Architect Panel → Security:
- Permissions — who can reach the error log
Why it helps so much
Knowing that a function failed is one thing; knowing it failed on a particular value is usually the answer. A date in an unexpected format, an empty identifier, a string longer than assumed — arguments turn "this sometimes fails" into "this fails on that".
Why it is dangerous
Arguments are the actual data being processed. Whatever was flowing through the failing code — personal data, a password being verified, an API token being used, the contents of a message — is what would otherwise be written into the error log.
An error log is typically less protected than the data it now contains, and it is often kept far longer.
Redaction is applied
The platform does not simply dump what it captured. Before a trace is stored or printed, it is redacted: values whose parameter names indicate a secret are replaced, secret-looking keys are removed recursively from nested structures, and the live object attached to each frame — which would carry the caller's entire private state — is discarded.
This is done deliberately and early, before anything logs, prints or encodes the trace.
Redaction is not a guarantee
It removes what it can identify. It cannot identify a customer's name in a parameter called value, or personal data inside a payload being parsed.
So the honest position is: redaction reliably keeps credentials out, and does not promise to keep personal data out. Those are different assurances and the difference matters when deciding whether to enable this in production.
Recommended use
- Development and test — on. The diagnostic value is high and the data is not real.
- Production — off by default. Turn it on deliberately, to investigate a specific problem, and turn it off again.
Treating it as a temporary diagnostic rather than a standing setting gives you the benefit at the moment you need it without accumulating years of captured values.
If you leave it on
Restrict error log access to named administrators, set a short retention on the error log specifically, and include it in your record of what personal data you hold. All three are cheap; none of them happens by default.
Worked example
A payment integration fails for a small number of customers. Arguments are enabled for one afternoon, three failures are captured, and the traces show an address line containing a character the provider rejects. The setting is turned off the same day and the captured entries are removed once the fix is confirmed — so the diagnosis is obtained without leaving a standing collection of customer addresses in the error log.
Recommendations
- Off in production by default, on in development.
- Enable it as a temporary diagnostic and turn it off again.
- Do not rely on redaction for personal data — it protects credentials.
- Restrict and time-limit error log access if it stays on.