Conversation
|
Deployment Complete
|
|
✅ Trivy gate: no Critical/High issues. Trivy IaC (Terraform) Summary
Findings (top 50)
|
|
✅ Trivy gate: no Critical/High vulnerabilities. Trivy Image Scan SummaryImage: 900119715266.dkr.ecr.eu-west-2.amazonaws.com/whoami:feature-gpcapim-265-x-request-id
Findings (top 50)
|
|
| assert isinstance(headers["X-Request-ID"], str) | ||
| assert len(headers["X-Request-ID"]) >= 32 | ||
| # Verify it's a valid UUID by trying to parse it | ||
| from uuid import UUID |
There was a problem hiding this comment.
Move to import block at the top of the file.
| # Verify it's a valid UUID by trying to parse it | ||
| from uuid import UUID | ||
|
|
||
| UUID(headers["X-Request-ID"]) # Should not raise |
There was a problem hiding this comment.
To produce nicer error messages if/when the test fails:
| UUID(headers["X-Request-ID"]) # Should not raise | |
| try: | |
| UUID(headers["X-Request-ID"]) | |
| except: | |
| pytest.fail("Should not raise an error if this is genuinely a uuid") |
| # X-Request-ID should be auto-generated as a UUID | ||
| assert "X-Request-ID" in headers | ||
| assert isinstance(headers["X-Request-ID"], str) | ||
| assert len(headers["X-Request-ID"]) >= 32 | ||
| # Verify it's a valid UUID by trying to parse it |
There was a problem hiding this comment.
IMO, these are unnecessary. The final assertion, UUID(headers["X-Request-ID"]) will check for these.
| Calls ``GET /Patient/{nhs_number}``, which returns a single FHIR Patient | ||
| resource on success, then extracts a single :class:`PdsSearchResults`. | ||
|
|
||
| A new UUID is generated for the ``X-Request-ID`` header with each call. |
There was a problem hiding this comment.
You've stated this twice. I'm not sure it's need once.
There was a problem hiding this comment.
I would parameterise the header test so that only a single assertion is made per test.
You could also patch the uuid module to return a yest value and assert for that.
2 participants
Description
This makes the PdsClient generate a fresh UUID with each request to PDS and send it as the X-Request-Id header
Context
PDS requires a fresh X-Request-Id with every request. Previously we were expecting it to be generated by the consumer and passed in, but that is incorrect - it needs to be generated within the PDS module because it is specific to the PDS request and the consumer has no knowledge of it.
Type of changes
Checklist
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.