E3019 failing for code module since update

[randybasrs]

CloudFormation Lint Version

1.4.2

What operating system are you using?

Windows/AWS Serverless

Describe the bug

When we lint any templates with more than 1 entry for a registered code module, it triggers E3019: Primary identifiers {} should have unique values across the resources {'resource2', 'resource1'}. We can't seem to provide the custom schema with the primaryIdentifer value set via a .cfnlintrc file either as it appears to just be ignored. If we change the templates and schemas to use a custom resource type that isn't a code module the schema is picked up and properly lints E3019.

Expected behavior

Schemas for code modules should be supported via registry_schemas like other custom resource types

This seems to be mentioned tangentally in #1811 but in this case I already have the schema files, they just don't seem to work for anything ending with ::MODULE

Reproduction template

AWSTemplateFormatVersion: 2010-09-09
Resources:
  resource1:
    Type: CORP::Resource::MODULE
    Properties:
      UniqueName: resource1
      Description: Just a thing for things
      RepositoryName: Mathematics
      TargetTemplate: path/to/differentTemplate.yaml
      TargetAccount: !Sub ${AWS::AccountId}
  resource2:
    Type: CORP::Resource::MODULE
    Properties:
      UniqueName: resource2
      Description: Pipeline to maintain IAM permissions for code pipeline in ASRS-AWS-SR
      RepositoryName: Physics
      TargetTemplate: path/to/differentTemplate.yaml
      TargetAccount: !Sub ${AWS::AccountId}

{
  "typeName": "CORP::Resource::MODULE",
  "description": "A fun little resource",
  "additionalProperties": false,
  "properties": {
    "UniqueName": {
      "type" : "string"
    },
    "Description": {
      "type" : "string"
    },
    "RepositoryName": {
      "type" : "string"
    },
    "TargetTemplate": {
      "type" : "string"
    },
    "TargetAccount": {
      "type" : "string"
    }
  },
  "primaryIdentifier": [ "/properties/UniqueName" ]
}

Note that this is a simplified schema as the code module has parameters rather than only properties.

registry_schemas:
  - .\

[kddejong]

Thanks for reporting this there are two things the PR will address.

1. When primary identifiers are empty don't do any primary identifier validation
2. When loading a schema for a resource type from the schema manager we will validate if the resource type has been loaded by the user before normalizing the resource type

We normalize the ::module resource type to do minimal validation and not create false positives. In your use case you are providing that parameter so we should see if we have a type available before escaping to a generic module schema.