Remove trigger kwargs from the REST API response

[potiuk]

Why

TriggerResponse.kwargs returned the decrypted trigger keyword arguments verbatim — and only as a stringified Python dict, not a usable JSON value. Those kwargs can carry credentials a deferred operator hands to its trigger (an API key, a token, …), so the field both leaked secrets and wasn't machine-readable. It isn't consumed by the UI.

What

Per review, rather than masking the value, the kwargs field is removed from TriggerResponse entirely. The triggerer still decrypts and uses the real kwargs at runtime, so trigger execution is unaffected — only the API response no longer exposes them.

• Regenerated the v2 REST + private-UI OpenAPI specs and the UI TypeScript client.
• Updated the task-instance API tests (the deferred-state response no longer carries trigger.kwargs).

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 4.8)

Generated-by: Claude Code (Opus 4.8) following the guidelines

[ashb]

This will fundamentally break any trigger that gets caught by this. This is not merely display. It is changing the value that the Trigger class sees.

You say:

the triggerer still decrypts and
uses the real kwargs at runtime, so trigger execution is unaffected.

But how/where is that done?

[potiuk]

But how/where is that done?

The redact_kwargs is only called explicitly and only in one place - in the "TriggerResponse" that is passed as the regular API response (not TaskSDK).

We are running it in BeforeValidator, which means that this redaction takes place before the response is prepared to be wired to be sent as response of API call.

https://pydantic.dev/docs/validation/latest/api/pydantic/functional_validators/#pydantic.functional_validators.BeforeValidator

I looked where TriggerResponse - and seems that this class is only used in responses in regular REST API.

or am I wrong @ashb ?

[ashb]

Ah no I was wrong.

So my other comment (about is this even worth returning stands) but if it does make sense to keep this:

This shouldn't have str() on it -- value is almost certainly a dict, which means this is relying on the stringification of a python dict, rather than keeping it as a json value.

[ashb]

Thinking about it, if this is part of the normal public API, not something used by the triggerer directly, perhaps we should just remove the trigger_kwargs from the response entirely?

[ashb]

Suggested change

	# The sensitive value is masked; the key name and non-sensitive values are preserved.
	assert "super-secret-value-123" not in kwargs
	assert "'gemini_api_key': '***'" in kwargs
	assert "'polling_interval': 30" in kwargs
	# The sensitive value is masked; the key name and non-sensitive values are preserved.
	assert kwargs == {"gemini_api_key": "***", "polling_interval": 30}

[potiuk]

Good call — dropped kwargs from TriggerResponse entirely rather than masking it. It only ever exposed the decrypted trigger kwargs (potential credentials) as a stringified dict, and it isn't read by the UI; the triggerer keeps decrypting and using the real kwargs at runtime, so nothing downstream changes. Regenerated the v2 + private-UI OpenAPI specs and the TS client, and updated the task-instance tests. Force-pushed the rewrite.

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[ashb]

Hmmmm, though removing this field means it's a breaking change on the API, and could possibly cause down stream consumers to fail with "no such property" type errors

[potiuk]

Yeah. Thought about it - what we could do instead is to leave it in but make it always empty. That is far less of a breaking change - the schema would remain and we could simply state in a documentation that it is here for historical reasons but kwargs are never populated.

I think this is. a bit of "Have cake and eat it too".

[potiuk]

Thanks @ashb — reworked based on your feedback. Rather than removing the field (which, as you noted, would be a breaking schema change for downstream consumers), TriggerResponse.kwargs is now retained in the schema but always returned empty as "{}".

Addressing your specific points:

• Not breaking: the field stays and keeps its existing str type, so the OpenAPI schema is unchanged — no missing-property errors for consumers, and no regenerated spec/UI client.
• On the str() concern: I kept it a string deliberately (it has always been one) rather than switching to an object, to avoid a schema type change. Since the value is now a constant "{}", it no longer leaks the real kwargs and no longer depends on stringifying a meaningful dict — "{}" is exactly what an empty-kwargs trigger already serialized to under the old str() behavior.
• The triggerer still decrypts and uses the real kwargs at runtime; only the API representation is emptied.

Added a unit test asserting sensitive kwargs are redacted to "{}", and updated the newsfragment. Could you take another look when you get a chance?

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting