Support for user specified server/sdk versions

[datoslabs]

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.

[jlegrone]

You can install multiple different Temporalite versions (as more are released). However Temporalite/Temporal server versions are tightly coupled since Temporalite uses the server project as a library, and I don't think this is likely to change any time soon.

You can already run any version of any language SDK against Temporalite, though this capability is of course limited if you're using the temporaltest package because that means Temporalite (and transitively Temporal server) is also consumed as a library in your tests. However we may add support for lazily installing different Temporal server versions as part of SDK specific test helpers, eg. TestWorkflowEnvironment in the TypeScript SDK. Does this latter approach make sense for your use case @datoslabs?

[datoslabs]

Yes, I think that would work. Also, it would help to align Temporalite version with Temporal server version numbers to make it easier for developers to install the correct version of Temporalite for their target production environment. As a side question, I have not come across documentation on the language-specific SDK version support by Temporal server version; do you know where I can find this info?

[cretz]

Yes, I think that would work. Also, it would help to align Temporalite version with Temporal server version numbers to make it easier for developers to install the correct version of Temporalite for their target production environment.

We may be able to do this in the downloading APIs, but in general this is difficult to rely on. Temporal server release cadence may not match Temporalite. We may be able to provide a table somewhere that shows which versions are which Temporalite versions, but relying on older Temporalite which may have had since-fixed bugs is a bit concerning.

Why can't you use the latest Temporalite? Newer Temporal is meant to be backwards compatible with older Temporal servers. Temporalite isn't suggested for production, and if you're counting on nuanced differences between your production server version and Temporalite in your tests, who knows what differences your missing with a different database, different configuration, etc. If you're concerned you may use newer features in tests than you do in production, those same concerns may exist with the environment/configuration too.

I would strongly suggest that if older versions are important to you because your test relies on such specific detail, you use local docker compose.

I have not come across documentation on the language-specific SDK version support by Temporal server version; do you know where I can find this info?

These are brand new. https://typescript.temporal.io/api/classes/testing.TestWorkflowEnvironment#createlocal in TypeScript and https://python.temporal.io/temporalio.testing.workflowenvironment#start_local in Python will lazily download Temporalite and start it.

[datoslabs]

Valid concerns regarding the challenges associated with aligning Temporalite and Temporal server release cadence; a table mapping Temporalite version and Temporal server version would be a helpful alternative.

Why can't you use the latest Temporalite?

Since I don't yet have a production deployment, I have already refreshed my SDK and server to use the latest. I am looking at down the road when I have a production environment that is running an earlier version what would be the best approach for my developers to run their tests locally. Temporalite, IMHO, is an invaluable solution for developers to test their code locally; among other benefits, it has a far smaller memory footprint (compared to local dev cluster via docker-compose) and does not require WSL (if running on Windows). It would greatly improve developers' experience if there is a way for devop teams to standardize Temporalite "configuration" to match various environments so that developers have one less thing to worry about.

I will give TestWorkflowEnvironment a try; is there a future roadmap to offer IDE plugins so developers can deploy and run their workflow test harness right from their IDE?

[cretz]

a table mapping Temporalite version and Temporal server version would be a helpful alternative.

:+1: In the meantime, you can look at the go.mod file in tags.

I am looking at down the road when I have a production environment that is running an earlier version what would be the best approach for my developers to run their tests locally.

I think you'll find this isn't a concern due to our compatibility stance for the server. All of your devs can use the latest Temporalite but I would recommend running something matching your production system more closely (version, database, ElasticSearch, etc) in CI for more than just version reasons.

is there a future roadmap to offer IDE plugins so developers can deploy and run their workflow test harness right from their IDE?

While there are ideas for IDE plugins for certain debug items, there is not really a plan to make a plugin for a simple, single-line command. If necessary, we can show how to start a binary from a button in your favorite IDE or, once Temporalite is containerized, show how to run code in a container e.g. in vscode.

[jlegrone]

There are some good ideas discussed here. For now we don't have plans to support dynamically pulling in specific versions of Temporal server via Temporalite, so I'm going to close this issue.

Going forward however, I hope to at least make the question of "what Temporal server version is in a Temporalite release?" easier to answer by including this information in the release notes published here: https://github.com/temporalio/temporalite/releases.

You can also find out which version of Temporal server is embedded in an existing temporalite binary by running temporalite --version.