Description
NotificationHistoryResponseValidator.notificationHistoryResponseItemValidator is initialized with new NotificationHistoryResponseValidator() instead of new NotificationHistoryResponseItemValidator().
As a result, each entry in notificationHistory is checked for response-level fields (paginationToken, hasMore and notificationHistory) rather than its own signedPayload and sendAttempts fields. Since the response-level fields are optional, malformed item objects can pass validation without their actual fields being inspected.
The correct item validator already exists and validates both signedPayload and the nested sendAttempts array, but the parent response validator does not use it.
Reproduction
From the repository root, after building the package:
const {
NotificationHistoryResponseValidator,
} = require('./dist/models/NotificationHistoryResponse.js');
const {
NotificationHistoryResponseItemValidator,
} = require('./dist/models/NotificationHistoryResponseItem.js');
const responseValidator = new NotificationHistoryResponseValidator();
const itemValidator = new NotificationHistoryResponseItemValidator();
for (const item of [
{ signedPayload: 123 },
{ sendAttempts: 'not-an-array' },
{ sendAttempts: [{ attemptDate: 'not-a-number' }] },
]) {
console.log(
responseValidator.validate({ notificationHistory: [item] }),
itemValidator.validate(item)
);
}
All three cases print true false: the outer response validator accepts the object while the correct item validator rejects it.
Expected behavior
If a history item contains an invalid signedPayload, sendAttempts, or nested send-attempt field, validating the containing NotificationHistoryResponse should return false.
Impact
AppStoreServerAPIClient.getNotificationHistory uses this response validator, so malformed history entries can pass the client's runtime response validation and reach callers under an incompatible TypeScript type.
This is a response-shape validation problem. The item validator is not responsible for verifying the cryptographic signature of signedPayload.
Suggested change
Import and instantiate the existing item validator:
import {
NotificationHistoryResponseItem,
NotificationHistoryResponseItemValidator,
} from './NotificationHistoryResponseItem';
// Inside NotificationHistoryResponseValidator:
static readonly notificationHistoryResponseItemValidator =
new NotificationHistoryResponseItemValidator();
Add regression coverage showing that malformed item fields cause the containing response to fail validation, while valid items and omitted optional fields remain accepted.
Description
NotificationHistoryResponseValidator.notificationHistoryResponseItemValidatoris initialized withnew NotificationHistoryResponseValidator()instead ofnew NotificationHistoryResponseItemValidator().As a result, each entry in
notificationHistoryis checked for response-level fields (paginationToken,hasMoreandnotificationHistory) rather than its ownsignedPayloadandsendAttemptsfields. Since the response-level fields are optional, malformed item objects can pass validation without their actual fields being inspected.The correct item validator already exists and validates both
signedPayloadand the nestedsendAttemptsarray, but the parent response validator does not use it.Reproduction
From the repository root, after building the package:
All three cases print
true false: the outer response validator accepts the object while the correct item validator rejects it.Expected behavior
If a history item contains an invalid
signedPayload,sendAttempts, or nested send-attempt field, validating the containingNotificationHistoryResponseshould return false.Impact
AppStoreServerAPIClient.getNotificationHistoryuses this response validator, so malformed history entries can pass the client's runtime response validation and reach callers under an incompatible TypeScript type.This is a response-shape validation problem. The item validator is not responsible for verifying the cryptographic signature of
signedPayload.Suggested change
Import and instantiate the existing item validator:
Add regression coverage showing that malformed item fields cause the containing response to fail validation, while valid items and omitted optional fields remain accepted.