Skip to content

Conversation

@THardy98
Copy link
Contributor

@THardy98 THardy98 commented Dec 2, 2025

What was changed

DWISOTT

  1. Part of Assume TLS enabled if API key provided in SDKs features#687

  2. How was this tested:
    Unit tests

  3. Any docs updates needed?
    Maybe

@THardy98 THardy98 changed the title enable TLS if api key specified 💥 Enable TLS if api key specified Dec 2, 2025
@THardy98 THardy98 force-pushed the enable-tls-api-key branch 2 times, most recently from c5c054f to b3277e8 Compare December 2, 2025 17:37
@THardy98 THardy98 marked this pull request as ready for review December 2, 2025 19:41
@THardy98 THardy98 requested a review from a team as a code owner December 2, 2025 19:41
var interopOptions = options.ToInteropOptions(scope);

// TLS should be auto-enabled when API key is provided and TLS not explicitly set
Assert.True(interopOptions.tls_options != null);
Copy link
Contributor

Choose a reason for hiding this comment

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

Assert.NotNull will give better error message when condition fails.

var interopOptions = options.ToInteropOptions(scope);

// TLS should remain disabled when explicitly set to null
Assert.True(interopOptions.tls_options == null);
Copy link
Contributor

Choose a reason for hiding this comment

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

Assert.Null will give better error message when condition fails.

using Temporalio.Client;
using Xunit;

public unsafe class TemporalConnectionOptionsTests
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you add tests for when:

  1. ApiKey is not set, is null, or is empty?
  2. Tls is set to a non-null value?

Comment on lines 117 to 120
/// <summary>
/// Gets a value indicating whether TLS was explicitly set (even to null).
/// </summary>
internal bool TlsExplicitlySet { get; private set; }
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we should take this approach. The difference between a user manually doing = null and the default of null would be very confusing. I think for .NET we should add a bool Disabled property to TlsOptions for users that want to explicitly disable TLS. null should be considered unset/default (regardless of whether it's set that way)

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, this is a bit nicer. Done

Copy link
Member

@cretz cretz Dec 3, 2025

Choose a reason for hiding this comment

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

Hrmm, these tests may be bit too detailed/low-level. You are testing internals and only relying on us making internals visible to this test project. Note we don't have any other tests confirming the bridge options conversions. Usually we test user-facing behavior.

How would a user write a test to confirm their setting of TLS disabled or API key or whatever does the right thing? Granted it's probably not very easy to do this. One approach that you may take is to alter the "Test cloud" CI test to use API key instead of mTLS to at least confirm the API key default.

Regardless, not a big deal if you keep these, just a bit strange for this repo (and why there never was anything like this in the past).

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.

4 participants