Skip to content

Conversation

papafe
Copy link
Contributor

@papafe papafe commented Feb 18, 2025

No description provided.

@papafe papafe marked this pull request as ready for review February 18, 2025 07:47
@papafe papafe requested a review from a team as a code owner February 18, 2025 07:47
@papafe papafe requested review from JamesKovacs and sanych-sun and removed request for a team and JamesKovacs February 18, 2025 07:47
@papafe
Copy link
Contributor Author

papafe commented Feb 18, 2025

@sanych-sun there are two things I'm not super convinced:

  • Naming. Is DekCacheLifetimeMs a good name for the property? Internally this is called sometimes "dek cache lifetime", other times "key expiration" or "cache expiration". I used DekCacheLifetimeMs as it seems the most descriptive, but I'm open to possibilities.
  • Constructors. Both ClientEncryptionOption and AutoEncryptionOption have public constructors with optional parameters, and if we want to keep binary compatibility we can't simply add a new optional parameter to the same constructor or add another constructor with the optional param (otherwise the compiler does not understand which constructor to use). For now I've added methods to both classes to the cache lifetime, but I'm not convinced by this since it is a different flow from the other parameters, and also this means that the property is not readonly anymore. The other possibility would be maybe to add another constructor in which the cache lifetime is one of the non-optional parameters, but I'm also not super fan of this.
    Any suggestions/ideas regarding those two?

(I also need to add input validation to be sure that the number of milliseconds isn't negative)

/// <summary>
/// Gets the value of the expiration time for the DEK cache in ms.
/// </summary>
public long? DekCacheLifetimeMs { get; }
Copy link
Member

Choose a reason for hiding this comment

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

Is there a compelling reason to use a long here instead of a TimeSpan? .NET typically prefers TimeSpans for durations as they're easier to configure in terms of code and you don't need suffixes then like "Ms" on the end.

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 issue here would be that TimeSpan has a greater granularity (microseconds) than the corresponding input for libmongocrypt (milliseconds).
We could also approximate the value if microseconds are used, but I'm not super convinced. I agree that maybe it would be easier to read with TimeSpan, even though more verbose.

Copy link
Member

@sanych-sun sanych-sun Feb 19, 2025

Choose a reason for hiding this comment

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

I suppose we should use TimeSpan. And pass TotalMilliseconds portion of it to libmongocrypt.

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, or we could also throw an exception if there is microseconds.

/// <summary>
/// Gets the value of the expiration time for the DEK cache in ms.
/// </summary>
public long? DekCacheLifetimeMs { get; }
Copy link
Member

@sanych-sun sanych-sun Feb 19, 2025

Choose a reason for hiding this comment

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

I suppose we should use TimeSpan. And pass TotalMilliseconds portion of it to libmongocrypt.

@papafe papafe requested review from damieng and sanych-sun February 24, 2025 10:03
@papafe
Copy link
Contributor Author

papafe commented Feb 24, 2025

@damieng @sanych-sun I've changed the name to KeyExpiration and used TimeSpan for its type.
I'm still not sure about the public API. In particular the constructors (copied from my previous message).
Both ClientEncryptionOption and AutoEncryptionOption have public constructors with optional parameters, and if we want to keep binary compatibility we can't simply add a new optional parameter to the same constructor or add another constructor with the optional param (otherwise the compiler does not understand which constructor to use). For now I've added methods to both classes to the cache lifetime, but I'm not convinced by this since it is a different flow from the other parameters, and also this means that the property is not readonly anymore. The other possibility would be maybe to add another constructor in which the cache lifetime is one of the non-optional parameters, but I'm also not super fan of this.

@sanych-sun
Copy link
Member

sanych-sun commented Mar 5, 2025

Please also rebase to let tests run on latest and rapid variants.

@papafe papafe requested a review from sanych-sun March 6, 2025 13:29
Copy link
Member

@sanych-sun sanych-sun left a comment

Choose a reason for hiding this comment

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

LGTM + minor comments.

Also I do not like SetKeyExpiration method, but have no better suggestions to it. Please get somebody else opinion/suggestion on it.


/// <summary>
/// Sets the data encryption key cache expiration time. If not set, it defaults to 60 seconds.
/// If set to 0, the cache never expires.
Copy link
Member

Choose a reason for hiding this comment

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

Should we mention TimeSpan.Zero instead of 0? Here and in AutoEncryptionOptions class as well.

IMongoClient keyVaultClient = null;
CollectionNamespace keyVaultCollectionNamespace = null;
IReadOnlyDictionary<string, IReadOnlyDictionary<string, object>> kmsProviders = null;
long? keyExpirationMs = null;
Copy link
Member

Choose a reason for hiding this comment

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

Minor: I would use TimeSpan? here instead. To eliminate that pattern matching in line 760.

@sanych-sun sanych-sun self-requested a review March 6, 2025 18:04
@papafe papafe merged commit 5829cca into mongodb:main Mar 11, 2025
19 of 30 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants