Amazon Partner EventBridge resource name violates name constraints

This is a Bug Report

Description

When a Lambda subscribes to a custom event source in Amazon EventBridge, the resource name (such as the Rule that is created) contains the partner prefix which includes slash (/) characters that fail Amazon’s validation. In addition to this, the prefix takes up a large portion of the 64 characters allowed for an ARN identifier.

For events sourced from Segment.com, the rule ARN looks like the following:

aws.partner/segment.com/XXXXXXXXXX/dispatcher-dev-create-request-sf-rule-1

The error output (shown below) says the name does not comply with Amazon’s regular expression pattern of: [\.\-_A-Za-z0-9]+.

The partner prefix (aws.partner/segment.com/XXXXXXXXXX/) takes up 35 characters of the identifier, and with the service, stage, and function name included, this particular example is 74 characters long, which surpasses Amazon’s 64 character limit.

In addition to this prefix taking up space and failing validation, the creation of EventBridge resources like this rule do not throw an error during deployment. Instead, the deploy completes as expected and then the rule is shown as an error in the AWS Console, displaying the following error in the interface:

There was an error while retrieving details for rule aws.partner/segment.com/XXXXXXXXXX/dispatcher-dev-create-request-sf-rule-1.
Details: 2 validation errors detected: 
Value 'aws.partner/segment.com/XXXXXXXXXX/dispatcher-dev-create-request-sf-rule-1' at 'name' failed to satisfy constraint: Member must satisfy regular expression pattern: [\.\-_A-Za-z0-9]+; 
Value 'aws.partner/segment.com/XXXXXXXXXX/dispatcher-dev-create-request-sf-rule-1' at 'name' failed to satisfy constraint: Member must have length less than or equal to 64.

Similar or dependent issues:

• #6514
• #6518

Additional Data

• Serverless Framework Version you’re using: 1.50.0
• Operating System: macOS Mojave 10.14.6
• Stack Trace:
• Provider Error messages:

[pmuens]

Thanks for the update @trevorrecker 👍

After some fiddling I was finally able to reproduce the problem. Looking into a potential fix right now…

[justin-capalbo]

I don’t know if anyone else has had this issue recently but I still do on the most recent version of serverless.

There was an error while retrieving details for rule qa/text-analysis-rule-1.
Details: 1 validation error detected: Value 'qa/text-analysis-rule-1' at 'name' failed to satisfy constraint: Member must satisfy regular expression pattern: [\.\-_A-Za-z0-9]+.

Is there any way to override the name of the rule that’s generated by serverless? Same questions as @hamletrp .

I see a lot of comments on this issue and the closed PR referencing the length of the ARN as the problem. To me, it seems like the forward slash in the rule name is what is causing the error. I’m running serverless deploy for the following configuration using v1.67.0:

    text-analysis:
        handler: src/lambda/textAnalysis.handler
        memorySize: 256
        events:
            - eventBridge:
                eventBus: 'arn:aws:events:xxxxxxxxxxxxxxxxxxxxxx:event-bus/bus-name'
                pattern:
                    source:
                        - 'xx.xxxx.xx'
                    detail-type:
                        - 'xxxxxx.xxxxxxxxxxxxxx'

The generated rule looks like this:

bus-name/xxxxxx-xxxxxxx-xx-text-analysis-rule-1

This is well within the 60 character limit. The error from AWS when trying to view the rule, though, is the one I’ve pasted above. I’m not using a “partner” eventbus - I’m using a custom one called bus-name (the real name is 7 characters). Does that matter?

Edit: This is bizarre but maybe answers my question. If I navigate to the rule directly through the custom bus in the EventBridge console, I can see that it exists and there are no errors when trying to view it. It’s only when I try to navigate to the rule by clicking the link in the lambda that I get this error. Very odd indeed - not sure what to make of this. I’m going to test the lambda itself to see if it’s functional.

Edit 2: Confirmed that it’s functional. Just no idea why navigating to the rule from the lambda directly would be a problem. Maybe it’s an issue in AWS console.