IMN-883 Add token-generation-readmodel-checker-verifier

[shuyec]

Closes IMN-583
Merge after #1094

Added the token-generation-readmodel-checker-verifier package to compare the token generation read model with the read model.

[shuyec]

Is process.exit(1) needed for the script?

[galales]

on a second thought, despite the differences found, here the job has been completed successfully, so we can remove the process.exit(1) and let the job exit normally

[shuyec]

Removed

[shuyec]

Are missing token-generation-states entries considered errors or not?

[galales]

yes, they are if the rows should exist.
For each client, we expect

• if the client does not contain keys, the number of records in token-generation-states should be zero
• if the client does not contain purposes, the number of records in token-generation-states should be equal to the number of keys in the client
• if the client contains purposes, the number of records in token-generation-states should be equal to the number of keys in the client multiplied by the number of purposes

[shuyec]

Same question as this.

[galales]

As rule of thumb keep things simple and leverage on the type system when you need to access a field on an existing type. It will make the code more readable and maintainable 😁

[galales]

on a second thought, despite the differences found, here the job has been completed successfully, so we can remove the process.exit(1) and let the job exit normally

[galales]

do we check also API clients?

[galales]

any reason to not use names like

Suggested change

	dataA: PlatformStatesPurposeEntry[],
	dataB: TokenGenerationStatesClientPurposeEntry[],
	dataC: Purpose[]
	platformStates: PlatformStatesPurposeEntry[],
	tokenStates: TokenGenerationStatesClientPurposeEntry[],
	purposes: Purpose[]

?

[galales]

this is a bit over engineered, I suggest

Suggested change

	function getIdentificationKey<T extends { PK: string } | { id: string }>(
	obj: T
	): string {
	if ("PK" in obj) {
	return unsafeBrandId(obj.PK.split("#")[1]);
	} else {
	return obj.id;
	}
	}
	function getIdFromPrimaryKey(
	record: PlatformStatesBaseEntry
	): string {
	return unsafeBrandId(record.PK.split("#")[1]);
	}

and just access directly the field when you need the id.

[shuyec]

Removed function

[galales]

same code, just generally more readable and without mutable data

Suggested change

	const parsedPurpose = PlatformStatesPurposeEntry.safeParse(e);
	if (parsedPurpose.success) {
	// eslint-disable-next-line functional/immutable-data
	acc.platformPurposeEntries.push(parsedPurpose.data);
	} else {
	const parsedAgreement = PlatformStatesAgreementEntry.safeParse(e);
	if (parsedAgreement.success) {
	// eslint-disable-next-line functional/immutable-data
	acc.platformAgreementEntries.push(parsedAgreement.data);
	} else {
	const parsedCatalog = PlatformStatesCatalogEntry.safeParse(e);
	if (parsedCatalog.success) {
	// eslint-disable-next-line functional/immutable-data
	acc.platformCatalogEntries.push(parsedCatalog.data);
	} else {
	const parsedClient = PlatformStatesClientEntry.safeParse(e);
	if (parsedClient.success) {
	// eslint-disable-next-line functional/immutable-data
	acc.platformClientEntries.push(parsedClient.data);
	} else {
	throw genericInternalError("Unknown platform-states type");
	}
	}
	}
	}
	return acc;
	const parsedPurpose = PlatformStatesPurposeEntry.safeParse(e);
	if (parsedPurpose.success) {
	return {
	...acc,
	platformPurposeEntries: [...acc.platformPurposeEntries, parsedPurpose.data]
	};
	}
	const parsedAgreement = PlatformStatesAgreementEntry.safeParse(e);
	if (parsedAgreement.success) {
	return {
	...acc,
	platformAgreementEntries: [...acc.platformAgreementEntries, parsedAgreement.data]
	};
	}
	// Same for others
	throw genericInternalError("Unknown platform-states type");

[galales]

I may have misunderstood, but isn't this evaluating as error a valid record in token generation states that has a different purpose than the current one?

[galales]

let's add more details to the error

[galales]

may we rename the package to token-generation-readmodel-checker 🙏
(having both checker and verifier it's redundant)

[galales]

note: comments on purpose logics apply also to the orthers

[galales]

yes, they are if the rows should exist.
For each client, we expect

• if the client does not contain keys, the number of records in token-generation-states should be zero
• if the client does not contain purposes, the number of records in token-generation-states should be equal to the number of keys in the client
• if the client contains purposes, the number of records in token-generation-states should be equal to the number of keys in the client multiplied by the number of purposes