Skip to content

Conversation

@aulme
Copy link
Contributor

@aulme aulme commented May 14, 2025

No description provided.

@aulme aulme force-pushed the aul-UID2-5349-logging-salt-stats branch 3 times, most recently from 7904e04 to d8e1775 Compare May 14, 2025 09:56
@aulme aulme force-pushed the aul-UID2-5349-logging-salt-stats branch from d8e1775 to 6ebc73b Compare May 14, 2025 09:58
return minInclusive <= t && t < maxExclusive;
private boolean isRotatable(long nextEffective, SaltEntry salt) {
if (this.isRefreshFromEnabled) {
if (salt.refreshFrom() == null) { // TODO: remove once refreshFrom is no longer optional

Choose a reason for hiding this comment

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

Is it still optional? I thought we've populated this everywhere now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, in practice we have that populated in every environment, there are still code paths for null case though. I'll remove it from here, we can clean up the others later.

return Result.fromSnapshot(nextSnapshot);
}

private List<Integer> findRotatableSaltIndexes(SaltEntry[] preRotationSalts, long nextEffective) {

Choose a reason for hiding this comment

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

Is there a reason why we can't use salt bucket IDs rather than indexes?

Choose a reason for hiding this comment

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

could even just pass around arrays of salt entries and override its equal method if that works better

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We could, I wanted to be consistent with how saltIndexesToRotate is done, which is indexes.

I guess that's done for performance reasons, so we can address specific indexes in the array of >1m rather than cycling through it. I can look at how much difference switching to objects across the board would make, might not be enough to matter.

if (shouldRotate) {
return salt.currentSalt();
}
long age = nextEffective - salt.lastUpdated();

Choose a reason for hiding this comment

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

Should we add a SaltEntry.ageInDays(asOf) method?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

SaltEntry is in Shared and currently this isn't needed anywhere except Admin. I guess we might need this for Operator though so might be ok.

Choose a reason for hiding this comment

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

I think Operator checks salt age as well, so would be broadly useful

Choose a reason for hiding this comment

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

We could just have one Admin helper function for this if we don't want to add it to shared

}

for (var entry : ages.entrySet()) {
LOGGER.info("{} target-date={} age={} salts={}", logEvent, formattedDate, entry.getKey(), entry.getValue());

Choose a reason for hiding this comment

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

perhaps:
salts={} target-date={} age={} num_salts={}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What's salts vs num_salts here? logEvent?

Choose a reason for hiding this comment

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

salts would be the set of salts "rotatable-salts", "rotated-salts", etc. How were you planning on identifying the set of salts without a logfmt label, regex?

num_salts would be the number of salts

}

private void logSaltCounts(LocalDate targetDate, Instant nextEffective, SaltEntry[] preRotationSalts, SaltEntry[] postRotationSalts, List<Integer> rotatableSaltIndexes, List<Integer> rotatedSaltIndexes) {
var rotatableSalts = onlySaltsAtIndexes(preRotationSalts, rotatableSaltIndexes);

Choose a reason for hiding this comment

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

Can we pass in rotatableSalts, rotatedSalts (and saltsForRefresh) directly into this function?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

RotatableSalts are saltsForRefresh

@aulme aulme force-pushed the aul-UID2-5349-logging-salt-stats branch from 2d71626 to 7dbead3 Compare May 15, 2025 10:22
@aulme aulme force-pushed the aul-UID2-5349-logging-salt-stats branch 2 times, most recently from abc1d53 to 64eac21 Compare May 16, 2025 09:15
@aulme aulme force-pushed the aul-UID2-5349-logging-salt-stats branch from 64eac21 to 27e005b Compare May 16, 2025 09:38
if (shouldRotate) {
return salt.currentSalt();
}
if (targetDate.saltAgeInDays(salt) < 90) {

Choose a reason for hiding this comment

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

should this be less than or equal to? or less than?

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 should be <, not <= since this includes the day on which we actually rotated the salt when the age would be 0. This results in people seeing previousSalt for 90 days exactly.

The current behaviour is also less than, we're even testing for it in L295.

@aulme aulme merged commit 8ee1512 into main May 20, 2025
4 checks passed
@aulme aulme deleted the aul-UID2-5349-logging-salt-stats branch May 20, 2025 03:48
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.

5 participants