Summary

Certain processor relationships do not need to route FlowFiles anywhere and can be safely “terminated.” Terminating a relationship tells Clockspring that no further processing is required for FlowFiles sent to that relationship. This keeps processors valid and prevents build errors when a relationship is intentionally unused.

1. What “Terminate Relationship” Means

A terminated relationship is one that:

• Does not connect to another component

• Does not create a queue

• Discards FlowFiles routed to it

• Allows the processor to remain valid

Clockspring will not allow a processor to run unless every required relationship is either:

1. Connected to another component, or

2. Marked as terminated

Terminating a relationship simply acknowledges that the FlowFile’s lifecycle ends there.

2. Why Termination Is Useful

Every processor defines which relationships must be handled. If a relationship is not optional and is left unconnected, the processor becomes invalid.

Example:

A processor has:

• success

• failure

If you only connect success, you must either then connect failure to a processor or funnel or terminate the relationship, otherwise the processor cannot start.

Clockspring forces this so FlowFiles never disappear unintentionally.

3. When It’s Safe to Terminate a Relationship

Termination is appropriate when:

• You intentionally do not care about FlowFiles routed to that relationship

• You are building a pipeline where certain paths represent “end of flow”

• You want to ignore benign errors

• You want a processor to run even though a relationship will not be used

Common examples:

• failure on a processor where errors are non-critical

• unmatched outputs from RouteOnContent and those FlowFiles will not be needed

• original content no longer needed after transformation

• retry relationship when you do not want an external retry loop

4. When You Should NOT Terminate a Relationship

Termination should not be used when:

• Failure data should be logged, inspected, or stored

• You need visibility into items that did not match routing rules

• A downstream system depends on receiving all FlowFiles

• You expect to revisit or debug FlowFiles later

• Failure could cause silent data loss

If FlowFiles matter at all, do not terminate the relationship; instead route it to:

• A logging processor or function

• A funnel for staging

• A dead-letter-queue processor group

• A retry loop

5. Termination vs. Leaving a Relationship Unconnected

Clockspring requires you to intentionally choose one.

6. Termination Does Not Affect Other Relationships

Terminating one relationship does not change:

• How other relationships route

• Retry logic

• Processor performance

• Backpressure

Termination simply discards any FlowFiles that would be delivered to that relationship.

7. Termination and Dynamic Relationships

Dynamic relationships (RouteOnAttribute, RouteOnContent, etc.) behave differently:

• New dynamic relationships appear only after saving

• Removing a dynamic route leaves a dotted dead connection

• Dynamic routes also require termination if unused

• Users frequently forget to terminate “fallback” or “unmatched” relationships

If a relationship is configured but not routed or terminated, the processor will go to an invalid state and cannot be started.

8. Best Practices

• Always terminate unused required relationships
• Don’t terminate failures unless you truly don’t care
• Use funnels for “temporary termination”
• Terminate only after reviewing all relationships

9. Quick Rules to Remember

• Every relationship must be connected or terminated

• Terminated relationships drop FlowFiles intentionally

• Termination keeps processors valid

• Dynamic relationships must be terminated too

• Unconnected non-terminated relationships make processors invalid

• Terminate only when you truly do not need the FlowFile downstream

Related Articles

• Managing Relationship Connections

• Queues and Backpressure

• Retries, Yielding, and Penalization

• FlowFile Content vs Attributes