CCM-14201 - Client Subscription Management

[rhyscoxnhs]

Description

Context

Type of changes

• Refactoring (non-breaking change)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would change existing functionality)
• Bug fix (non-breaking change which fixes an issue)

Checklist

• I am familiar with the contributing guidelines
• I have followed the code style of the project
• I have added tests to cover my changes
• I have updated the documentation accordingly
• This PR is a result of pair or mob programming
• If I have used the 'skip-trivy-package' label I have done so responsibly and in the knowledge that this is being fixed as part of a separate ticket/PR.

---

Sensitive Information Declaration

To ensure the utmost confidentiality and protect your and others privacy, we kindly ask you to NOT including PII (Personal Identifiable Information) / PID (Personal Identifiable Data) or any other sensitive data in this PR (Pull Request) and the codebase changes. We will remove any PR that do contain any sensitive information. We really appreciate your cooperation in this matter.

• I confirm that neither PII/PID nor sensitive data are included in this PR and the codebase changes.

[cgitim]

Shouldn't we specify --environment and it figures out the bucket name itself?

[rhyscoxnhs]

The bucket naming convention follows the pattern: {project}-{account_id}-{region}-{environment}-{component}-{name}. To derive the bucket name from just --environment, we would need to:

• Know the AWS account ID (requires either hardcoding account mappings or making AWS STS API calls)
• Know the project name, region, and component name
• Maintain environment-to-account mappings

While this is definitely possible (we could make an STS GetCallerIdentity call), it adds complexity and requires AWS credentials to be properly configured just to construct the bucket name.

The current approach is more explicit and gives users flexibility to override if needed. Users can set the CLIENT_SUBSCRIPTION_BUCKET_NAME environment variable once in their shell profile to avoid repeating it.

[cgitim]

Only one of --channel-status or --supplier-status (or --message-statuses for that matter) can be provided at once. Do we check?

[rhyscoxnhs]

My current interpretation is that both --channel-statuses and --supplier-statuses are required together for channel status subscriptions. I based this on the data model specification (data-model.md lines 312-313) which states:

• ChannelStatuses must be a non-empty array of valid channel status values
• SupplierStatuses must be a non-empty array of valid supplier status values

However, I realize there's an alternate interpretation: these validation rules might mean "when present, must be non-empty", rather than "must always be present". This would allow subscriptions to filter on:

• Only channel statuses (e.g., only DELIVERED events)
• Only supplier statuses (e.g., only 'read' events)
• OR both together (e.g., DELIVERED + received/notified/read)

In this case, we'd need validation to ensure at least one is provided (not both omitted), but they wouldn't both be required.

Could you confirm which interpretation matches the intended design?