Skip to content

Conversation

chaptersix
Copy link

@chaptersix chaptersix commented Sep 9, 2025

What changed?

This PR allows the temporal://system callback URL at all times. If this URL is passed in as a Nexus Callback URL, it indicates the Callback will be routed within the Temporal System.

Why?

This is one step in allows Self-Hosted Temporal Servers to support nexus with zero dynamic configuration required.
See this issue:

How did you test it?

  • built
  • run locally and tested manually
  • covered by existing tests
  • added new unit test(s)
  • added new functional test(s)

Copy link
Contributor

@pdoerner pdoerner left a comment

Choose a reason for hiding this comment

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

I don't think you need to worry about whether to allow insecure connections for temporal://system since those internally-routed requests will always use our internal local frontend client which should have already been configured with the correct secure/insecure setting.

@chaptersix chaptersix marked this pull request as ready for review September 11, 2025 17:59
@chaptersix chaptersix requested a review from a team as a code owner September 11, 2025 17:59
@chaptersix chaptersix requested a review from bergundy September 11, 2025 18:24
Copy link
Member

@bergundy bergundy left a comment

Choose a reason for hiding this comment

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

We also discussed setting temporal://system only for worker targets in nexusoperations/executors.go, external targets would still require a URL to be configured.

Comment on lines 56 to 57
URLs are checked against each in order when starting a workflow with attached callbacks and only need to match one to pass validation. URL: "temporal://system" is always valid.
Default is no address rules. Any invalid entries are ignored. Each entry is a map with possible values:
Copy link
Member

Choose a reason for hiding this comment

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

Could you just merge the two statements saying that tempral://system is always valid and the default is no address rules just to clarify a bit? Also mention that this config is required for external endpoint targets.

Comment on lines 5269 to 5270
if cfg.MatchHost(u.Host) {
if !cfg.CheckSchemeSecureLevel(u.Scheme) {
Copy link
Member

Choose a reason for hiding this comment

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

I would change this signature to cfg.Allow(url) error.
This will allow you to match temporal://system properly because you need to verify both the scheme and the host together and the regexp based validation doesn't work here.

Copy link
Author

Choose a reason for hiding this comment

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

awesome, I was thinking about going this direction.

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.

3 participants