HTTP service trigger is killed at startup: an action definition is frozen at its first deploy

Symptom

An HTTP-service trigger starts and is killed 3–4 s later. The Worker logs:

Error while generating inputs : ryax_endpoint_port with value 8080.0

The action never serves a request. Reported against 26.9.0.

Root cause — confirmed in the code

The Worker receives the values the HTTP addon injects, but the action definition has no definitions for them, so input generation raises ExecutionIODefinitionNotFoundError (core/ryax/worker_k8s/infrastructure/ryax_execution/grpcv1/grpc_v1_execution_service.py:214).

The definitions are missing because an action definition is written once and never updated. core/ryax/runner/application/handlers/action_definition_handlers.py:35-72:

try:
    action_definition = uow.action_definition_repository.get(cmd.id)
    # ... refreshes container_image only ...
    return action_definition.id            # <-- early return
except ActionDefinitionNotFoundError:
    action_definition = ActionDefinition(
        ..., inputs=cmd.inputs, outputs=cmd.outputs,
        addons_inputs=cmd.addons_inputs, resources=cmd.resources, ...
    )

inputs, outputs, addons_inputs, resources and has_dynamic_outputs are only ever set in the except branch — at the definition's first deploy. Every later deploy of the same action returns early. So an action first deployed without addons keeps addons_inputs empty permanently, and adding the HTTP addon afterwards changes nothing in the Runner's stored definition.

This is why it reproduced here: the demo's first deploy came from an import, and imports drop addons — see the companion issue for that.

This is the same defect as #1435 (closed), one field over

#1435 (closed) ("Action image registry host is frozen at the action's first deploy") is the same early return. Its fix carved out container_image specifically — the comment at line 40-43 explains why — and left every other field frozen. The general problem was not addressed.

Reproduction

  1. Deploy a workflow whose HTTP-service trigger has no addon (or import one, which strips them).
  2. Add the HTTP addon and deploy again.
  3. The pod starts and is killed; the Worker logs the error above.

Two checks that would confirm the mechanism directly:

  • SELECT addons_inputs FROM action_definition WHERE id = '<action id>' before and after the second deploy — expected to be unchanged.
  • Deploy the same action with the addon first, on a clean database; expected to work, which isolates first-deploy ordering as the trigger.

Workaround in place

The demo's trigger versions declare ryax_endpoint_port and the prefix as their own inputs, so the definition carries them regardless of the addon.

Suggested fix

Refresh the mutable parts of the definition on re-deploy rather than only container_image, or version the definition so a changed action surface produces a new row. Deciding which is the real work here; #1435 (closed) shows the field-by-field patch does not generalise.

Found while migrating the CAPE demo to Ryax 26.9.0: ryax-tech/public/cape-tools/cape-agentic-infra#2 (comment 3905714558)