FLX-1008

2 node(s) can record audit values but this graph has no event audit configured: [priceSource, riskCheck]. To record them: DataFlow DSL .build(EventLogControlEvent.LogLevel.INFO); builder config cfg.addEventAudit(EventLogControlEvent.LogLevel.INFO); Spring XML <property name="logLevel" value="INFO"/> on the FluxtionSpringConfig bean. Records print to System.out (redirect with dataFlow.setAuditLogProcessor(...)); open them in the Fluxtion analyser: https://telaminai.github.io/fluxtionauditlog-analyser/ . Ignore this if the nodes never call auditLog.

Severity	WARN
Category	AUDIT
Element	NODE

The rule

A graph with audit-capable nodes and no event audit records nothing they log.

Why the compiler says this

These nodes implement EventLogSource — usually by extending EventLogNode — so Fluxtion gives them an auditLog to write to. Without an event audit registered there is no auditor to receive those records, so anything they write is discarded silently. The builder cannot tell whether they DO write; it can only see that they could.

How to fix it

If you expect an audit log, enable it at INFO or above. DataFlow DSL: end the chain with .build(EventLogControlEvent.LogLevel.INFO) instead of .build(). Builder config (Fluxtion.compile/interpret, EventProcessorConfig): cfg.addEventAudit(EventLogControlEvent.LogLevel.INFO). Spring XML: <property name="logLevel" value="INFO"/> on the FluxtionSpringConfig bean. Each event then prints one audit record to System.out; send them elsewhere with dataFlow.setAuditLogProcessor(...). Save the records to a file and open it in the Fluxtion audit log analyser (https://telaminai.github.io/fluxtionauditlog-analyser/) to see, per event, which nodes ran and what they logged. If these nodes never call auditLog, this warning is noise and nothing needs changing.

Example

Both examples are compiled and put through a real Fluxtion.compile on every build, so the first is guaranteed to produce this diagnostic and the second to build cleanly. Note that the failing example is valid Java — javac is happy, and Fluxtion refuses it for its own reasons.

The code that causes it

package com.telamin.fluxtion.builder.diagnostic.examples;

import com.telamin.fluxtion.builder.generation.config.EventProcessorConfig;
import com.telamin.fluxtion.runtime.annotations.OnEventHandler;
import com.telamin.fluxtion.runtime.audit.EventLogNode;

/** FLX-1008 — a node that can audit, in a graph with no audit configured. */
public class Flx1008Failing {

    public static class PriceSource extends EventLogNode {
        @OnEventHandler
        public boolean onPrice(String symbol) {
            // Writes to an auditLog that no auditor is listening to: discarded silently.
            auditLog.info("symbol", symbol);
            return true;
        }
    }

    public static void graph(EventProcessorConfig config) {
        config.addNode(new PriceSource(), "priceSource");
        // nothing registers an audit, so nothing receives what the node logs
    }
}

The code that fixes it

package com.telamin.fluxtion.builder.diagnostic.examples;

import com.telamin.fluxtion.builder.generation.config.EventProcessorConfig;
import com.telamin.fluxtion.runtime.annotations.OnEventHandler;
import com.telamin.fluxtion.runtime.audit.EventLogControlEvent.LogLevel;
import com.telamin.fluxtion.runtime.audit.EventLogNode;

/** FLX-1008 fixed — an audit is registered, so the records are kept. */
public class Flx1008Fixed {

    public static class PriceSource extends EventLogNode {
        @OnEventHandler
        public boolean onPrice(String symbol) {
            auditLog.info("symbol", symbol);
            return true;
        }
    }

    public static void graph(EventProcessorConfig config) {
        config.addNode(new PriceSource(), "priceSource");
        // If these nodes never call auditLog, the warning is noise and needs no change —
        // the compiler can see that they COULD write, not whether they do.
        config.addEventAudit(LogLevel.INFO);
    }
}

Which builds raise it

Every build path — interpreted, in-process and AOT alike.

Reading it programmatically

This diagnostic is also written to the machine-readable report — the opt-in sidecar (-Dfluxtion.diagnostics.sidecar=true), or FluxtionDiagnostics.capture(...) for a caller that wants the objects:

{
  "code": "FLX-1008",
  "severity": "WARN",
  "category": "AUDIT",
  "element": { "kind": "NODE", … }
}

Select findings by severity, never by position: a failing build's report also contains any warnings it found, and diagnostics[0] is not the cause of the failure.

---

This page is generated from the compiler itself, so the wording above is exactly what a build emits. Do not edit it by hand — it is overwritten whenever the diagnostics are regenerated.