Skip to main content

​
Overview

Publishing a component or campaign fails with a generic campaign build failed 400 whose payload names a frontend controller and its name expression, and nothing else. This page explains what that combination means and why the entities you were creating are probably still there. If the error code is controller_state_misconfiguration instead, the build failed for a different reason: an email’s sending controller and the frontend controller that renders it are out of step. The last section of this page covers that error.

​
The Distinction That Matters

A build failure whose payload names a frontend controller together with its name field means two controllers resolve to the same name within the same journey in the campaign being built. The name expression itself is not the problem. It appears in the payload because it is how the colliding name was produced, not because it is malformed. Rewriting it does not help.

​
The Usual Configuration Behind It

The common cause is a component nested inside another copy of itself — a wrapper with a slightly different name but identical subcomponents. That produces two controllers resolving to one name and one journey, which the build rejects. Look for self-nesting first, then for any two controllers in the campaign that resolve to the same name.

​
The Failed Build Still Created the Entities

Despite the 400, the component and its subcomponents are usually created and simply left unpublished. So once you have removed the duplication you can publish what is already there, rather than building it again from scratch.
Check the component list before re-creating anything. Building a second copy of a component that already exists is how one duplicate becomes two.

​
What to Do

  1. Find the two controllers that resolve to the same name in the same journey, most often a component nested inside a copy of itself.
  2. Remove the duplication so one controller resolves to each name.
  3. Publish the component that the failed build already created.
If you cannot find the collision, contact Extole Support with the failed request and the campaign name. The 400 does not carry the underlying error, but Extole can retrieve it.

​
When the Error Is controller_state_misconfiguration

This build failure also names a frontend controller, but it carries its own error code, controller_state_misconfiguration, with the message “A controller has not properly configured state”. Unlike the name collision above, the payload says what is wrong: controller_id is the frontend controller, and details gives a cause and a message naming both controllers, the trigger, and the actions involved.

​
An Email Is Two Controllers

An email in a campaign is sent by two controllers that work as a pair:
  • The sending controller has an email action. That action names a zone.
  • The rendering frontend controller has an input event trigger that listens for that zone name, and an email creative action that produces the message.
When the sending controller fires, Extole renders the email through the frontend controller whose event name matches the zone. It uses only a frontend controller that is enabled and enabled for the campaign’s current state. If none qualifies, the email has no creative to render it, and Extole cancels the send.

​
What the Build Checks

The build pairs each enabled sending controller — one with an enabled email action and an enabled trigger — with each enabled frontend controller that listens for the email’s zone name and has an email creative action. For every pair, it fails with one of these two causes: The check runs one way only. A frontend controller can be enabled in more states than its sending controller.

​
What to Do

  1. Read details to find the cause and the IDs of the sending controller, its email action, the frontend controller, and its trigger.
  2. For INCOMPATIBLE_ENABLED_ON_STATES, add the missing campaign states to the frontend controller’s enabled_on_states, or remove them from the sending controller’s.
  3. For DISABLED_CREATIVE_ACTION, enable the frontend controller’s email creative action, or disable the sending controller’s email action.
  4. Publish again.

​
Turning an Email Off or On

Switch an email on the sending side. Disable the sending controller, or every email action on it, and the build no longer checks the pair. Do not turn an email off by disabling its creative action on the frontend controller while the sending controller’s email action is enabled. The build rejects that change with DISABLED_CREATIVE_ACTION.
Disabling the rendering frontend controller itself passes the build. The build skips a disabled frontend controller, so nothing stops the change. The sending controller still fires. If no other enabled frontend controller listens for the zone, nothing can render the email, and Extole cancels every send. Disable the sending controller instead.
When you change which campaign states an email runs in, change both controllers. Widen the frontend controller’s enabled_on_states before you widen the sending controller’s, and narrow the sending controller’s before you narrow the frontend controller’s.