RuleGo Component Aliases and Switch Reliability

RuleGo is a Go rule engine for component orchestration, data integration, and rule chains in data engineering workflows. Recent activity in rulego/rulego is small but practical: alias support makes old component names safer to carry forward, while the switch node now treats one bad case as a miss instead of a failed rule instance.

This week had only two commits, but one of them touched five files and accounts for nearly all of the 460 insertions. The component alias support changes an important boundary: compatibility is no longer scattered in endpoint creation with string checks. It moves into the component registry path used by rule nodes.

That matters when a data pipeline stores rule chains as JSON. A saved chain can contain node type values like js_filter while the runtime component is jsFilter. The new tests in engine/alias_test.go cover that exact shape. They create a chain with alias node types, initialize it, and assert that the original SelfDefinition type is preserved while the runtime node resolves to the primary type.

This is a useful trade for operators. Stored config remains readable and stable. Runtime lookup still converges on a canonical component. That reduces migration pressure when teams have rule chains created by older consoles, copied examples, or custom generators.

Endpoints got a similar cleanup in endpoint/registry.go. Older names like http, rest, ws, websocket, mqtt, net, tcp, schedule, and timer now map through aliases to their full endpoint types. The test added in endpoint/registry_test.go checks both legacy names and primary names.

The old logic used a local strings.Contains check inside endpoint construction. That is a sharp edge. It can confuse partial matches, and it only helps callers that pass through that endpoint constructor. After the alias change, endpoint creation delegates name resolution to the same underlying component registry.

For ETL style systems, this mostly helps config drift. RuleGo can receive data by HTTP, MQTT, TCP, websocket, and scheduled endpoints. Those names often live in exported config, not in source code. A registry level alias gives maintainers one place to decide which names are accepted.

The smaller switch case evaluation fix is only two changed files, but it has visible behavior. In components/common/switch_node.go, a template execution error inside one case no longer calls TellFailure and returns. RuleGo now logs the skip and continues checking later cases.

The test change in components/common/switch_node_test.go captures the behavior with a missing field, msg.temperature2. Before the fix, that missing field sent the message through Failure. After the fix, the failed case is treated as not matched, so the message can reach Default.

For event processing, this is a sensible default. A switch with several cases should not be as brittle as the most fragile expression, especially when messages may come from different device models or upstream sources. The tradeoff is that a bad expression can become less visible if debug logs are not collected. Teams that use switch cases as validation gates should check logs or add explicit validation before the switch.

This is mostly internal cleanup, but it affects how people operate RuleGo in real systems. Rule chains are configuration. Once they are stored in a database, exported into Git, or generated from a control plane, every naming change becomes migration work.

The alias work in engine/registry.go makes naming changes lower risk. It lets the registry accept several external names while keeping one implementation type. That is useful when a project has both old samples and current docs in circulation.

The switch fix has the same operational flavor. It is not a new feature. It reduces the blast radius of one expression error inside a branch. In a message flow, that can be the difference between one unmatched case and a failure route that looks like pipeline health has degraded.

First, confirm how aliases interact with custom components. The tests cover jsFilter, jsTransform, endpoint names, and direct node creation. If you register custom node types, register aliases near the component registration path and add tests that verify both the stored name and resolved type.

Second, watch logging around switch nodes after this behavior change. If a case starts skipping because a field is missing, the flow may still complete through Default. That can be correct, but it can also hide a schema mismatch from a source topic or webhook payload.

Third, treat this as compatibility work, not a reason to keep every old name forever. Aliases are useful when they are documented and bounded. They become noise when nobody knows which name is canonical.