Why Does Ignition ResourceValidator Flag Itself as Duplicate?

A ResourceValidator<MyResource> that checks the (fieldA, fieldB) pair against every other resource of the type fails on each update and on each read. validate(MyResource resource) receives only the decoded config object. It gets no name, no enabled flag, and no other metadata, so the check cannot tell "another resource holds this pair" apart from "I hold this pair." Every resource matches itself. The validation API checks one decoded config in isolation and was not designed for cross-resource rules. The permanent repair moves the check into a custom ResourceCodec, where decoding works on the raw Resource and its metadata.

Stop patching the validator: why each quick fix breaks

The validator runs whenever the config is decoded, not only when a user saves. That includes GET requests. When it returns errors on a read, the response still lists every resource with its metadata, but the config field is missing on each one.

Quick fixes people try first, and why they fail:

• Allow one match, reject two. This passes duplicate creates, because the new resource is not stored yet and the existing duplicate is the only hit.
• Skip the check if the config is equal to a stored one. A duplicate is by definition equal on fieldA/fieldB, so this skips the case you are trying to catch.
• Skip validation on reads. validate() gets no signal telling it whether the call is a read or a write.

Restore reads first: pull uniqueness out of the validator

This is the temporary restore. Get configuration visible and editable again before you build the real fix.

1. Remove the cross-resource lookup from MyResourceValidator.validate().
2. Keep only single-resource checks there: field presence, ranges, formats, and anything decidable from MyResource alone.
3. Rebuild and redeploy the module.

Check: run a GET on the resource type. Every entry must come back with its config populated. Save an existing resource without changes, and it must succeed. Duplicates are unguarded until the codec is in place, so keep this build off shared gateways or limit who can create resources.

Wire a custom ResourceCodec into the type meta

Register a codec with DefaultResourceTypeMeta.Builder::withCodec. With a custom codec you decode the raw Resource instead of receiving an already-decoded config, so the resource's name and other metadata are in scope. That name is what lets the uniqueness check exclude the resource being evaluated.

// Sketch: match method signatures to the ResourceCodec interface in your SDK build
public static final ResourceTypeMeta<MyResource> META =
    ResourceTypeMeta.newBuilder(MyResource.class)
        .resourceType(RESOURCE_TYPE)
        .categoryName("My Settings")
        .withCodec(new MyResourceCodec())      // uniqueness lives here
        .withValidator(new MyResourceValidator()) // single-resource checks only
        ...;

Two decisions before you write the codec:

• Delegate or hand-roll. If your build lets you get at the codec the builder would otherwise use, wrap it. Delegate decode and encode to it, and add only the uniqueness check. If it does not, you are decoding the raw resource data into MyResource yourself. In that case, write encode and decode together and round-trip test them.
• Keep encode untouched. The check belongs on decode only. Encode must write whatever it is given.

Check: add a debug log line in decode that prints the resource name. Trigger a GET and a save, and confirm the codec runs on both and logs the correct name for each resource.

Query existing resources through the NamedResourceHandler

The codec gives you the resource's own identity. You still need the list of other resources. In this installation, a module singleton already holds the resource type's NamedResourceHandler and is the source for existing resources. Call it from the codec.

// Sketch: identifiers other than those named in this article are placeholders
public MyResource decode(/* raw Resource */ raw) throws DecodingException {
    MyResource cfg = decodeConfig(raw);          // delegate or hand-rolled
    String selfName = /* name from raw Resource metadata */;

    boolean conflict = MySingleton.handler()     // wraps NamedResourceHandler
        .existing()                              // all resources of this type
        .stream()
        .filter(r -> !r.name().equals(selfName)) // exclude self
        .anyMatch(r -> r.fieldA().equals(cfg.fieldA())
                    && r.fieldB().equals(cfg.fieldB()));

    if (conflict) {
        throw new ValidationException(/* message naming fieldA/fieldB and the other resource */);
    }
    return cfg;
}

Settle these points before you trust the lookup:

• Recursion. If fetching existing resources through the handler decodes them with this same codec, each lookup re-enters the uniqueness check. Read the stored configs through a path that does not call back into your check, or keep a separate index of (fieldA, fieldB) → name maintained by the singleton.
• Disabled resources. Decide whether a disabled resource still reserves its pair. If two resources may share a pair while one is disabled, filter on enabled in the lookup. Enabling the second one must then be treated as a write that re-runs the check.
• Null or blank fields. Decide whether two resources with empty fieldB collide. Apply that rule in the comparison, not in the UI.

Check: with two resources holding different pairs, log the match set for each decode. The match set must be empty for both.

Throw ValidationException so the user sees the rejection

ValidationException is a DecodingException, so throwing it from ResourceCodec::decode reports a failed decode back through the same path a validator failure uses. The user gets an error on save, not a silent drop. No separate pre-create lifecycle hook is needed; decode is the hook.

1. Throw only when a resource with a different name holds the same pair.
2. Name the conflicting resource in the message, so the operator knows which one to change.
3. Do not catch and swallow the exception inside the codec.

Check: create resource A with pair (x, y), then try to create resource B with (x, y). The create must fail with your message, and resource B must not appear in a subsequent GET.

Close the gaps: rename, stored duplicates, concurrent saves

Name-based self-exclusion has edge cases. Test each one before calling the fix permanent.

Check: rename resource A to A2 without changing its pair. The save must succeed, and a GET must show A2 with config populated and no A.

Run the end-to-end acceptance matrix

Run every row on a test gateway after the final build. Every row must pass before the module goes to production.

Row 10 catches startup ordering problems. If the codec decodes resources before the singleton holding the NamedResourceHandler is ready, fix the initialization order. Do not skip the check when the handler is null; that turns into a silent pass.

FAQ

Stop and contact Inductive Automation official support if decode is not called on the write path in your SDK build, or if you cannot read the resource name from the raw Resource. Do the same if the NamedResourceHandler cannot be queried from inside decode without recursion. Bring the module's type meta registration, the codec source, and the gateway log lines from a failed save.