Arguments to each function call massively improve diagnostic value — you see not just where the code went but what data it was working with. But they cost more to capture and may contain sensitive information. This article covers the tradeoffs and configuration.
What Gets Included
- Scalar arguments (numbers, strings, booleans) shown inline.
- Arrays and objects summarised — type and key count, e.g. array(7).
- Optionally a depth-limited dump of the values for short objects.
- Resources (DB connections, file handles) shown as type + ID.
Privacy and Redaction
Argument capture risks logging PII or secrets. The platform redacts known-sensitive parameter names automatically:
- password, password_hash, secret, api_key, token, card_number, cvv.
- Anything matching a configurable regex (e.g.
/.*_secret$/). - Field-level redaction via per-datastore declarations.
Performance Cost
Capturing arguments doubles or triples the trace generation cost (still microseconds, but it adds up at scale). Don't enable arguments in counts-only mode; do enable in incident-response mode.
Configuration
- Open Site Settings → Logs → Error Logging → Stack Traces.
- Toggle Include arguments in stack traces.
- Set argument-value depth (default 2 — dumps 2 levels into nested structures).
- Tune the redaction list.
- Save.
Worked Examples
- Standard production: Arguments disabled. Stack traces alone normally tell us enough.
- Live debugging session: Arguments enabled for 2 hours during an incident; reverted after.
- Sensitive workflow: Arguments disabled globally but a specific function annotated to capture them despite the rule.
- Heavy redaction: Regex pattern added to redact any field with “_pii_” or “national_id” in its name.