Skip to content

Comments

CCM-14199 - Foundational: Infrastructure as Code and Core Types#31

Open
mjewildnhs wants to merge 25 commits intomainfrom
feature/CCM-14199-foundation
Open

CCM-14199 - Foundational: Infrastructure as Code and Core Types#31
mjewildnhs wants to merge 25 commits intomainfrom
feature/CCM-14199-foundation

Conversation

@mjewildnhs
Copy link
Contributor

@mjewildnhs mjewildnhs commented Feb 10, 2026

Description

This PR establishes the foundational infrastructure and core type definitions for the NHS Notify Client Callbacks system. It includes:

  • Terraform Infrastructure: S3 bucket for client configuration storage
  • TypeScript Type System: Comprehensive type definitions for status events, callback payloads, and client configuration
  • Development Tooling: Updated ESLint configuration, Jest setup, Sonar scanner properties, and pre-commit hooks

Context

This work is part of CCM-14199 and lays the groundwork for externalizing client callbacks from the main Communications Manager system. The foundational infrastructure enables:

  1. Receiving status transition events from the internal EventBus
  2. Transforming and filtering events based on client-specific subscriptions
  3. Delivering callbacks to client webhooks with appropriate rate limiting

This foundation will be built upon in subsequent phases to add full transformation logic, error handling, DLQs, and monitoring.

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.

@mjewildnhs mjewildnhs force-pushed the feature/CCM-14199-foundation branch from 80e7546 to fd5a645 Compare February 10, 2026 16:13
@mjewildnhs mjewildnhs force-pushed the feature/CCM-14199-foundation branch 4 times, most recently from 5fdffbf to 2165b0e Compare February 11, 2026 14:58
@sonarqubecloud
Copy link

@mjewildnhs mjewildnhs force-pushed the feature/CCM-14199-foundation branch from d97e7b1 to a965084 Compare February 12, 2026 09:49
@mjewildnhs mjewildnhs force-pushed the feature/CCM-14199-foundation branch from 5e03c91 to 7ca4971 Compare February 13, 2026 16:02
@mjewildnhs mjewildnhs marked this pull request as ready for review February 18, 2026 14:50
@mjewildnhs mjewildnhs requested review from a team as code owners February 18, 2026 14:50
rhyscoxnhs
rhyscoxnhs previously approved these changes Feb 19, 2026
Copy link

@rhyscoxnhs rhyscoxnhs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Comment on lines +4 to +13
describe("EventTypes", () => {
it("should match the expected event type values", () => {
expect(EventTypes).toEqual({
MESSAGE_STATUS_TRANSITIONED:
"uk.nhs.notify.client-callbacks.message.status.transitioned.v1",
CHANNEL_STATUS_TRANSITIONED:
"uk.nhs.notify.client-callbacks.channel.status.transitioned.v1",
});
});
});
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a useful test?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No hence the "// coverage purposes" but sonar will fail coverage otherwise and i don't want to start adding exclusions

| "TECHNICAL_FAILURE"
| "ACCEPTED"
| "CANCELLED"
| "PENDING_VIRUS_CHECK"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also need a matching VIRUS_SCAN_FAILED? The API claims it can emit that, apparently.

What's odd though, is that is doesn't appear in SUPPLIER_STATUSES (commsTypes.ts) or getSupplierStatus.ts (which maps statuses to the API statuses), or in comms-mgr at all, as far as I can see. It doesn't look like we ever emit this supplier status in old callback mechanism. So maybe taking our PENDING_VIRUS_CHECK is the way to go?

Copy link
Contributor Author

@mjewildnhs mjewildnhs Feb 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah think we want to go off communications-manager-api/specification/schemas/enums/SupplierStatusEnum.yaml
I'll double check things would explode if VIRUS_SCAN_FAILED bever appeared

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the supplier status is normalized and mapped from the raw form in getSupplierStatus here:
https://github.com/NHSDigital/comms-mgr/blob/3382123d6c47b4f229a3919dd49c5ac8e7e277ee/packages/libs/routing-orchestrator/src/supplier-status/getSupplierStatus.ts#L78

This seems to make its way to the DB (in the lowercase form - which is inconsistent with the other statuses)

The current callback code passes this straight through as the callback payload.

The list of the website matches the list in the schema on the website here:
https://digital.nhs.uk/developer/api-catalogue/nhs-notify#post-/%3Cclient-provided-channel-status-URI%3E

Which is different to the list here:
https://notify.nhs.uk/using-nhs-notify/message-channel-supplier-status

I'm pretty sure we want the 23 lowercase options from here:
https://github.com/NHSDigital/comms-mgr/blob/3382123d6c47b4f229a3919dd49c5ac8e7e277ee/packages/libs/utils/src/types/commsTypes.ts#L301

I'll try and clear it up with someone

* Message-level statuses
*/
export type MessageStatus =
| "CREATED"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where did it get CREATED from? It's not in REQUEST_ITEM_STATUSES (commsType.ts), nor in the API...?

Copy link
Contributor Author

@mjewildnhs mjewildnhs Feb 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is the open api spec being wrong again

@cgitim cgitim requested a review from a team as a code owner February 19, 2026 13:29
/**
* Channel-level statuses
*/
export type ChannelStatus =
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing:

  • assigning_batch
  • retry
  • stale_pds

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The subscription types use the enum which includes the missing values
https://github.com/NHSDigital/comms-mgr/blob/0e19549a2794d0320d5fd0ca0925781520cc4ee5/packages/libs/utils/src/client-subscriptions/types.ts#L18
So presumably you could subscribe to them and its not just a case of a callback for those statuses not being possible

so again i think the spec is wrong

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants