Expected Behavior

the go install github.com/DataDog/temporalite/cmd/temporalite@latest command should produce the binary for temporalite without any errors.

Actual Behavior

Getting this error when trying to install temporalite as suggested in Getting started page

../pkg/mod/go.temporal.io/[email protected]/common/metrics/config.go:31:2: ambiguous import: found package github.com/cactus/go-statsd-client/statsd in multiple modules:
	github.com/cactus/go-statsd-client v3.1.1+incompatible (~/go/pkg/mod/github.com/cactus/[email protected]+incompatible/statsd)
	github.com/cactus/go-statsd-client/statsd v0.0.0-20200423205355-cb0885a1018c (~/go/pkg/mod/github.com/cactus/go-statsd-client/[email protected])

Steps to Reproduce the Problem

1. Execute this command go install github.com/DataDog/temporalite/cmd/temporalite@latest

Specifications

• Version: go1.16.3
• Platform: darwin/amd64

Potential Solution

Add this statement to go.mod file solved the problem on my side:

replace github.com/cactus/go-statsd-client => github.com/cactus/go-statsd-client v3.2.1+incompatible

This allows starting a temporalite instance with a remote data converter endpoint preconfigured.

What changed?

Adds a new --ui-codec-endpoint flag to temporalite start.

Why?

Exposing the flag allows to send a single command to run to users that can rely on a remote data converter hosted somewhere instead of telling them to run 2 processes on their laptop.

How did you test it?

Manually

Potential risks

None

Is hotfix candidate?

No

What changed?

Temporal and Temporal Web UI versions upgraded.

Why?

To benefit from the improved web UI.

How did you test it?

Ran locally and in gitpod.

Potential risks

None.

Is hotfix candidate?

No.

What changed? This bumps the Temporal sdk and server packages to v1.19.0.

Why? The Temporal SDK has made a breaking change to its NewServer interface, and as such consumers of temporalite are unable to use it with the latest Temporal SDK.

How did you test it? Ran unit tests locally.

Potential risks I am not a temporalite expert, only a user who was motivated to fix this issue to unblock my own work.

Is hotfix candidate? No, although the presence of upstream breaking changes and unstable cross-package dependencies which impact the community may suggest there is additional work here for the temporalio maintainers' release processes.

In case it helps, here's an example of a breaking change that affects SDK consumers, this removal (proto, go) of EVENT_TYPE_WORKFLOW_UPDATE_REQUESTED used by go.temporal.io/[email protected] was made in a non-breaking manner. Could consider enabling breaking change detection or adding proto fields rather than renaming (breaking) them.

Is your feature request related to a problem? Please describe. Hi,

First of all, thank you for all the great work on Temporal and Temporalite; I am "sort of" new here and am looking forward to incorporating Temporal framework into my project!

Would it be possible to use Temporalite to support the testing of different server and/or sdk versions? For example, if I have a project that was running sdk version 1.6 and server version 1.13; would it be possible to start Temporalite with those specifications for unit testing purposes?

Describe the solution you'd like Ability to start Temporalite with a configuration file or add command line arguments to specify server and sdk version.

Describe alternatives you've considered The only alternative I am aware of is to use docker-compose to run an actual dev Temporal server cluster with a specified version.

Additional context I had evaluated Temporal.io a couple of years back with sdk 1.2 (Temporal's Java sdk) and really liked how Temporal as a micro-service orchestration framework. Due to other priorities, I had to switch my focus and only recently started to revisit/incorporate Temporal into my project. I was pleasantly surprised and encouraged to see the tremendous progress the team had made, obviously, the evaluation code I wrote can simply be updated to work on the latest versions. As I proceed to refresh my old dev cluster with updated docker-compose, I saw Temporalite as an alternative to running a dev cluster and decided to give it a try. I think Temporalite is an extremely valuable tool for developers to test their workflow locally (and run CI) but I couldn't stop thinking what if a team's production environment is running a slightly older version, how could we make it easier for development teams to use Temporalite across server/sdk versions.

Is your feature request related to a problem? Please describe.

It seems goreleaser is setup, but there are no tags to trigger releases to build binaries. Having downloadable binaries helps users of Temporalite who don't want to build. For my use case in particular, the Python SDK would love to download and run Temporalite instead of building it in CI.

Describe the solution you'd like

Tag releases. Granted I can't figure out what the best release numbering scheme would be considering this is also a Go library so must remain on semver, but it may make sense to align with server version.

(this is obviously non-urgent as building Temporalite is trivial)

Expected Behavior

Temporalite could create the directory first, then start writing to the database file.

Actual Behavior

User sees an error message like

2022/04/04 18:57:43 error setting up schema: unable to create SQLite admin DB: unable to open database file: no such file or directory

The error text doesn't include the file path that is being opened, which makes understanding the issue a bit more difficult.

Steps to Reproduce the Problem

1. temporalite start -f some_dir_that_does_not_exist/foo.db

Specifications

• Version: main
• Platform: Any

What changed?

Updates ui-server to the latest ~tagged release~ commit. ~Dependabot should be able to start tracking new versions going forward.~

Update: We're still unable to use a tagged release until a new version is cut now that https://github.com/temporalio/ui/pull/267 is merged.

Why?

How did you test it?

Potential risks

Is hotfix candidate?

What changed?

This adds support for search attributes:

Defines two new startup flags to pre-register search attributes: search-attributes-type & search-attributes-key. If the user gives values for these flags (multiple values must be separated by a comma), then temporalite will initialize the custom search attributes as defined in the user input. In addition to this, we also give the ability to pre-register search attributes on a temporalite TestServer.

How did you test it?

Tests are included.

Expected Behavior

Temporalite installs successfully using go install

Actual Behavior

Installation fails with the following error:

go: github.com/temporalio/temporalite/cmd/[email protected] (in github.com/temporalio/[email protected]):
	The go.mod file for the module providing named packages contains one or
	more replace directives. It must not contain directives that would cause
	it to be interpreted differently than if it were the main module.

Steps to Reproduce the Problem

1. Run go install github.com/temporalio/temporalite/cmd/[email protected]
2. Installation fails with mentioned error

Specifications

• Version: 0.2.0
• Platform: darwin-amd64

What changed?

Two changes:

1. Allow temporal web/ui to be configured from a yaml file so that the web UI does not break when the API is configured for mTLS.
2. Since the UI cannot be run via HTTPS, allow the UI to be bound to a different IP than the API. This can facilitate the API with mTLS being exposed to non-local clients, while keeping the UI available to localhost.

Why?

Temporalite is great, and I want to use it safely in situations where I'm experimenting with mTLS in temporal, especially while implementing mTLS in workers, without the UI being broken.

How did you test it?

Ran temporalite locally without any TLS, and with TLS certificates created by a self-signed root CA. The latter required the creation of temporalite.yaml and temporalite-ui.yaml files in a configuration directory, to allow mTLS to be set up for temporal API components, and allow the UI to make requests to the API via mTLS.

Updated the ui unit test to verify that it can still create a valid configuration when the temporalite-ui.yaml file is absent even though a config directory has been provided, and that it loads the file when it is present.

Updated the mtls test to verify proper integration between the UI and the API when mtls is enabled.

temporalite.yaml

global:
  tls:
    internode:
      server:
        certFile: dist/local.dev+2-client.pem
        keyFile: dist/local.dev+2-client-key.pem
        requireClientAuth: true
        clientCaFiles:
          - dist/rootCA.pem
      client:
        serverName: local.dev
        rootCaFiles:
          - dist/rootCA.pem
    frontend:
      server:
        certFile: dist/local.dev+2-client.pem
        keyFile: dist/local.dev+2-client-key.pem
        requireClientAuth: true
        clientCaFiles:
          - dist/rootCA.pem
      client:
        serverName: local.dev
        rootCaFiles:
          - dist/rootCA.pem

# dummy values, required by yaml parser
# replaced at runtime by temporalite
persistence:
  defaultStore: default
  numHistoryShards: 1

temporalite-ui.yaml

tls:
  caFile: dist/rootCA.pem
  certFile: dist/client.pem
  keyFile: dist/client-key.pem
  serverName: local.dev

Potential risks

Applications with existing command line configuration will still work as advertised.

Is hotfix candidate?

No.

Bumps github.com/temporalio/ui-server/v2 from 2.8.3 to 2.9.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps github.com/urfave/cli/v2 from 2.23.5 to 2.23.7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Expected Behavior

The error that is being raised is super misleading when the address is already binded to another process. Ideally we should get something like

: Address already in use - bind(2) for "127.0.0.1" port 3001 (Errno::EADDRINUSE)
... backtrace ...

Actual Behavior

Panic error with no context in it.

❯ ./spec/support/go_server/main 3000 s                                                                                                                    [3.1.2]
2022/12/07 22:55:29 Let's do this!
2022/12/07 22:55:29 Starting server on port 3000 for namespace s
panic: Client must be created with client.Dial() or client.NewLazyClient()

goroutine 203 [running]:
go.temporal.io/sdk/internal.NewWorker(...)
        /Users/laertipapa/go/pkg/mod/go.temporal.io/[email protected]/internal/worker.go:233
go.temporal.io/sdk/worker.New({0x0?, 0x0?}, {0x300c11c?, 0x23?}, {0xa, 0x0, 0x0, 0x0, 0x0, 0x8, ...})
        /Users/laertipapa/go/pkg/mod/go.temporal.io/[email protected]/worker/worker.go:223 +0xdd
go.temporal.io/server/service/worker/scanner.(*Scanner).Start(0xc00030d8f0)
        /Users/laertipapa/go/pkg/mod/go.temporal.io/[email protected]/service/worker/scanner/scanner.go:153 +0x7a6
go.temporal.io/server/service/worker.(*Service).startScanner(0xc0002d8180)
        /Users/laertipapa/go/pkg/mod/go.temporal.io/[email protected]/service/worker/service.go:472 +0x22a
go.temporal.io/server/service/worker.(*Service).Start(0x0?)
        /Users/laertipapa/go/pkg/mod/go.temporal.io/[email protected]/service/worker/service.go:374 +0x3dc
go.temporal.io/server/service/worker.ServiceLifetimeHooks.func1.1({0x34d8248?, 0xc0002d8180?}, 0xc000368880?)
        /Users/laertipapa/go/pkg/mod/go.temporal.io/[email protected]/service/worker/fx.go:155 +0x2c
created by go.temporal.io/server/service/worker.ServiceLifetimeHooks.func1
        /Users/laertipapa/go/pkg/mod/go.temporal.io/[email protected]/service/worker/fx.go:153 +0x98

Steps to Reproduce the Problem

1. Compile the server running here: https://github.com/temporalio/sdk-ruby/tree/main/spec/support/go_server
2. Start which ever process you like locally in port X
3. Try to run the go server in port X: ./main 3001 s

Bumps go.uber.org/zap from 1.23.0 to 1.24.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Vulnerable Library - github.com/temporalio/ui-server/v2-v2.8.3

Golang Server for https://github.com/temporalio/ui

Library home page: https://proxy.golang.org/github.com/temporalio/ui-server/v2/@v/v2.8.3.zip

Found in HEAD commit: fdc0165780ae650730a59957dc8b227794444190

Vulnerabilities

| CVE | Severity | CVSS | Dependency | Type | Fixed in (github.com/temporalio/ui-server/v2-v2.8.3 version) | Remediation Available | | ------------- | ------------- | ----- | ----- | ----- | ------------- | --- | | WS-2021-0461 | Medium | 6.1 | github.com/temporalio/ui-server/v2-v2.8.3 | Direct | swagger-ui - 4.1.3;swagger-ui-dist - 4.1.3 | ❌ | | CVE-2018-25031 | Medium | 4.3 | github.com/temporalio/ui-server/v2-v2.8.3 | Direct | swagger-ui - 4.1.3;swagger-ui-dist - 4.1.3 | ❌ |

Details

WS-2021-0461

Vulnerable Library - github.com/temporalio/ui-server/v2-v2.8.3

Golang Server for https://github.com/temporalio/ui

Library home page: https://proxy.golang.org/github.com/temporalio/ui-server/v2/@v/v2.8.3.zip

Dependency Hierarchy:

• :x: github.com/temporalio/ui-server/v2-v2.8.3 (Vulnerable Library)

Found in HEAD commit: fdc0165780ae650730a59957dc8b227794444190

Found in base branch: main

Vulnerability Details

SwaggerUI supports displaying remote OpenAPI definitions through the ?url parameter. This enables robust demonstration capabilities on sites like petstore.swagger.io, editor.swagger.io, and similar sites, where users often want to see what their OpenAPI definitions would look like rendered.

However, this functionality may pose a risk for users who host their own SwaggerUI instances. In particular, including remote OpenAPI definitions opens a vector for phishing attacks by abusing the trusted names/domains of self-hosted instances.

Resolution: We've made the decision to disable query parameters (#4872) by default starting with SwaggerUI version 4.1.3. Please update to this version when it becomes available (ETA: 2021 December). Users will still be able to be re-enable the options at their discretion. We'll continue to enable query parameters on the Swagger demo sites.

Publish Date: 2021-12-09

URL: WS-2021-0461

CVSS 3 Score Details (6.1)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: Required
  • Scope: Changed
• Impact Metrics:
  • Confidentiality Impact: Low
  • Integrity Impact: Low
  • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://github.com/advisories/GHSA-qrmm-w75w-3wpx

Release Date: 2021-12-09

Fix Resolution: swagger-ui - 4.1.3;swagger-ui-dist - 4.1.3

CVE-2018-25031

Vulnerable Library - github.com/temporalio/ui-server/v2-v2.8.3

Golang Server for https://github.com/temporalio/ui

Library home page: https://proxy.golang.org/github.com/temporalio/ui-server/v2/@v/v2.8.3.zip

Dependency Hierarchy:

• :x: github.com/temporalio/ui-server/v2-v2.8.3 (Vulnerable Library)

Found in HEAD commit: fdc0165780ae650730a59957dc8b227794444190

Found in base branch: main

Vulnerability Details

Swagger UI before 4.1.3 could allow a remote attacker to conduct spoofing attacks. By persuading a victim to open a crafted URL, an attacker could exploit this vulnerability to display remote OpenAPI definitions.

Publish Date: 2022-03-11

URL: CVE-2018-25031

CVSS 3 Score Details (4.3)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: Required
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: Low
  • Integrity Impact: None
  • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://github.com/advisories/GHSA-qrmm-w75w-3wpx

Release Date: 2022-03-11

Fix Resolution: swagger-ui - 4.1.3;swagger-ui-dist - 4.1.3

What changed?

I added a -buildvcs=false flag to the go build step inside the dockerfile.

Why?

This is a workaround to https://github.com/temporalio/temporalite/issues/156 I'm not sure if this is the best way to do this, but it does work.

How did you test it?

I ran docker build . before and after the change.

Potential risks

This may strip VCS information that someone is using, I am not sure if it is necessary to use this flag in the docker image.

Is hotfix candidate?

No