add dprint and remove unmaintained docsync script

README.md

@@ -47,6 +47,10 @@ TypeScript code gets transpiled to JavaScript code during the build process. Any
 
 As a result, all code you include needs to be complete, or the site will fail to build.
 
+## dprint
+
+Consider running `yarn format` after the Snipsync toolchain or after making other edits. This runs `dprint` using the same configuration as the documentation repo, and should take care of dedenting and other formatting issues.
+
 ## Run the development server
 
 To preview the site, run the local server with the following command:

docs/tutorials/go/background-check/durable-execution.mdx

@@ -37,7 +37,6 @@ tags:
 - timer
 ---
 
-
 When it comes to the Temporal Platform's ability to durably execute code, the SDK's ability to [Replay](https://docs.temporal.io/dev-guide/sdks#replays) a Workflow Execution is a major aspect of that.
 This chapter introduces the development patterns which enable that.
 
@@ -140,7 +139,6 @@ From the Workflow details page you can copy the Event History from the JSON tab
 
 ## Add a Replay test {#add-replay-test}
 
-
 Add the Replay test to the set of application tests.
 The Replayer is available from the `go.temporal.io/sdk/worker` package in the SDK.
 Register the Workflow Definition and then specify an existing Event History to compare to.
@@ -149,9 +147,10 @@ Run the tests in the test directory (`go test`).
 If the Workflow Definition and the Event History are incompatible then the test fails.
 
 <!--SNIPSTART go-durability-chapter-replay-test-->
+
 [docs/tutorials/go/background-check/code/durability/tests/backgroundcheck_test.go](https://github.com/temporalio/temporal-learning/blob/main/docs/tutorials/go/background-check/code/durability/tests/backgroundcheck_test.go)
-```go
 
+```go
 // TestReplayWorkflowHistoryFromFile tests for Event History compatibility.
 func (s *UnitTestSuite) TestReplayWorkflowHistoryFromFile() {
 	// Create a new Replayer
@@ -163,8 +162,8 @@ func (s *UnitTestSuite) TestReplayWorkflowHistoryFromFile() {
 	err := replayer.ReplayWorkflowHistoryFromJSONFile(nil, "backgroundcheck_workflow_event_history.json")
 	s.NoError(err)
 }
-
 ```
+
 <!--SNIPEND-->
 
 ### Why add a Replay test? {#why-replay-test}
@@ -184,7 +183,6 @@ Workflow code becomes non-deterministic primarily through two main avenues:
 
 ## Intrinsic non-deterministic logic {#intrinsic-non-deterministic-logic}
 
-
 Referred to as "intrinsic non-determinism" this kind of "bad" Workflow code can prevent the Workflow code from completing because the Workflow can take a different code path than the one expected from the Event History.
 
 The following are some common operations that **can't** be done inside of a Workflow Definition:
@@ -196,10 +194,10 @@ The following are some common operations that **can't** be done inside of a Work
   - Use `workflow.Now()` as a replacement for `time.Now()`.
   - Use `workflow.Sleep()` as a replacement for `time.Sleep()`.
 - Working directly with threads or goroutines.
-	- Use `workflow.Go()` as a replacement for the `go` statement.
-    - Use `workflow.Channel()` as a replacement for the native `chan` type.
-	Temporal provides support for both buffered and unbuffered channels.
-	- Use `workflow.Selector()` as a replacement for the `select` statement.
+  - Use `workflow.Go()` as a replacement for the `go` statement.
+  - Use `workflow.Channel()` as a replacement for the native `chan` type.
+    Temporal provides support for both buffered and unbuffered channels.
+  - Use `workflow.Selector()` as a replacement for the `select` statement.
 - Iterating over data structures with unknown ordering.
   This includes iterating over maps using `range`, because with `range` the order of the map's iteration is randomized.
   Instead you can collect the keys of the map, sort them, and then iterate over the sorted keys to access the map.
@@ -210,7 +208,9 @@ The following are some common operations that **can't** be done inside of a Work
 One way to produce a non-deterministic error is to use a random number to determine whether to sleep inside the Workflow.
 
 <!--SNIPSTART go-durability-chapter-non-deterministic-workflow-->
+
 [docs/tutorials/go/background-check/code/durability/workflows/backgroundcheck_non_deterministic_code.go](https://github.com/temporalio/temporal-learning/blob/main/docs/tutorials/go/background-check/code/durability/workflows/backgroundcheck_non_deterministic_code.go)
+
 ```go
 // CAUTION! Do not use this code!
 package workflows
@@ -247,8 +247,8 @@ func BackgroundCheckNonDeterministic(ctx workflow.Context, param string) (string
 	}
 	return ssnTraceResult, nil
 }
-
 ```
+
 <!--SNIPEND-->
 
 If you run the BackgroundCheckNonDeterministic Workflow enough times, eventually you will see a Workflow Task failure.
@@ -391,7 +391,6 @@ The [Event reference](https://docs.temporal.io/references/events) serves as a so
 
 ### Add a call to sleep {#add-sleep-call}
 
-
 In the following sample, we add a couple of logging statements and a Timer to the Workflow code to see how this affects the Event History.
 
 Use the `workflow.Sleep()` API to cause the Workflow to sleep for a minute before the call to execute the Activity.
@@ -400,7 +399,9 @@ The Temporal SDK offers both a `workflow.StartTimer()` API, and a `workflow.Slee
 Use the `workflow.GetLogger` API to log from Workflows to avoid seeing repeated logs from the Replay of the Workflow code.
 
 <!--SNIPSTART go-durability-chapter-workflow-->
+
 [docs/tutorials/go/background-check/code/durability/workflows/backgroundcheck.go](https://github.com/temporalio/temporal-learning/blob/main/docs/tutorials/go/background-check/code/durability/workflows/backgroundcheck.go)
+
 ```go
 package workflows
 
@@ -438,13 +439,12 @@ func BackgroundCheck(ctx workflow.Context, param string) (string, error) {
 	// Make the results of the Workflow available
 	return ssnTraceResult, nil
 }
-
 ```
+
 <!--SNIPEND-->
 
 ### Inspect the new Event History {#inspect-new-event-history}
 
-
 After updating your Workflow code to include the logging and Timer, run your tests again.
 You should expect to see the `TestReplayWorkflowHistoryFromFile` test fail.
 This is because the code we added creates new Events and alters the Event History sequence.
@@ -484,4 +484,3 @@ The following are a few examples of changes that do not lead to non-deterministi
 - Modifying non-Command generating statements in a Workflow Definition, such as logging statements
 - Changing attributes in the `ActivityOptions`
 - Modifying code inside of an Activity Definition
-

docs/tutorials/go/background-check/index.mdx

@@ -21,5 +21,3 @@ The tutorial is laid out in the following chapters:
 - [Introduction](/tutorials/go/background-check/introduction)
 - [Project setup](/tutorials/go/background-check/project-setup)
 - [Develop for durability](/tutorials/go/background-check/durable-execution)
-
-

docs/tutorials/go/background-check/introduction.mdx

@@ -25,15 +25,15 @@ If you are reading this, chances are you already have some notion of why you wan
 However, if you are still unsure, there are three major reasons why Temporal might be right for you.
 
 1. **Reliabile execution.**
-  With Temporal, you can rely on your application to work.
-  The design of the system ensures that, once started, an application's main function executes to completion, whether that takes minutes, hours, days, weeks, or even years.
-  Temporal calls this "Durable Execution".
+   With Temporal, you can rely on your application to work.
+   The design of the system ensures that, once started, an application's main function executes to completion, whether that takes minutes, hours, days, weeks, or even years.
+   Temporal calls this "Durable Execution".
 
 2. **Code structure.**
-  Temporal's programming model offers developers a way to express their business logic into coherent "Workflows" that are much easier to develop than distributed code bases.
+   Temporal's programming model offers developers a way to express their business logic into coherent "Workflows" that are much easier to develop than distributed code bases.
 
 3. **State visibility.**
-  The Temporal system provides out-of-the-box tooling that enables developers to see the state of their applications whenever they need to.
+   The Temporal system provides out-of-the-box tooling that enables developers to see the state of their applications whenever they need to.
 
 ## Audience
 

docs/tutorials/go/background-check/project-setup.mdx

@@ -358,12 +358,13 @@ go get go.temporal.io/sdk
 
 ### Boilerplate Workflow code {#workflow-code}
 
-
 In the Temporal Go SDK programming model, a [Workflow Definition](https://docs.temporal.io/workflows#workflow-definition) is an exportable function.
 The `BackgroundCheck` function below is an example of a basic Workflow Definition.
 
 <!--SNIPSTART setup-chapter-workflow-->
+
 [docs/tutorials/go/background-check/code/setup/workflows/backgroundcheck.go](https://github.com/temporalio/temporal-learning/blob/main/docs/tutorials/go/background-check/code/setup/workflows/backgroundcheck.go)
+
 ```go
 package workflows
 
@@ -392,8 +393,8 @@ func BackgroundCheck(ctx workflow.Context, param string) (string, error) {
 	// Make the results of the Workflow available
 	return ssnTraceResult, nil
 }
-
 ```
+
 <!--SNIPEND-->
 
 The first parameter of a Go-based Workflow Definition must be of the [`workflow.Context`](https://pkg.go.dev/go.temporal.io/sdk/workflow#Context) type.
@@ -419,12 +420,13 @@ For example, in a small project like this, it is still a best practice to have a
 
 ### Boilerplate Activity code {#activity-code}
 
-
 In the Temporal Go SDK programming model, an Activity is an exportable function or a `struct` method.
 Below is an example of an Activity defined as a function.
 
 <!--SNIPSTART setup-chapter-activity-->
+
 [docs/tutorials/go/background-check/code/setup/activities/ssntraceactivity.go](https://github.com/temporalio/temporal-learning/blob/main/docs/tutorials/go/background-check/code/setup/activities/ssntraceactivity.go)
+
 ```go
 package activities
 
@@ -439,8 +441,8 @@ func SSNTraceActivity(ctx context.Context, param string) (*string, error) {
 	result := "pass"
 	return &result, nil
 }
-
 ```
+
 <!--SNIPEND-->
 
 The first parameter of an Activity Definition is `context.Context`.
@@ -462,7 +464,9 @@ To run a Worker Process with a local development server, define the following st
 In regards to organization, we recommend keeping Worker code separate from Workflow and Activity code.
 
 <!--SNIPSTART setup-chapter-worker-dev-->
+
 [docs/tutorials/go/background-check/code/setup/dev_server_worker/main.go](https://github.com/temporalio/temporal-learning/blob/main/docs/tutorials/go/background-check/code/setup/dev_server_worker/main.go)
+
 ```go
 package main
 
@@ -499,8 +503,8 @@ func main() {
 		log.Fatalln("Unable to start the Worker Process", err)
 	}
 }
-
 ```
+
 <!--SNIPEND-->
 
 :::info Auto restart worker when code changes
@@ -523,7 +527,9 @@ A Temporal Cloud Worker requires that you specify the following in the Client co
 - Certificate and private key associated with the Namespace
 
 <!--SNIPSTART setup-chapter-worker-cloud-->
+
 [docs/tutorials/go/background-check/code/setup/cloud_worker/main.go](https://github.com/temporalio/temporal-learning/blob/main/docs/tutorials/go/background-check/code/setup/cloud_worker/main.go)
+
 ```go
 package main
 
@@ -584,19 +590,19 @@ func main() {
 		log.Fatalln("Unable to start the Worker Process", err)
 	}
 }
-
 ```
+
 <!--SNIPEND-->
 
- To run a Temporal Cloud Worker, you'll change some parameters in your Client connection code, such as updating the namespace and gRPC endpoint.
- You'll use:
- 
- - The [Temporal Cloud Namespace Id](https://docs.temporal.io/cloud/namespaces#temporal-cloud-namespace-id).
- - The [Namespace's gRPC endpoint](https://docs.temporal.io/cloud/namespaces#temporal-cloud-grpc-endpoint).
- The endpoint uses this format `(namespace.unique_id.tmprl.cloud:port)`.
- - [Paths to the SSL certificate (.pem) and private key (.key)](https://docs.temporal.io/cloud/saml#integrate-saml-with-your-temporal-cloud-account) registered to your Namespace and stored on your Worker's file system.
- 
- Copy the Namespace Id and the gRPC endpoint from the Namespace detail Web page on [Temporal Cloud Namespaces](https://cloud.temporal.io/namespaces). Click on a Namespace name to open the Namespace details.
+To run a Temporal Cloud Worker, you'll change some parameters in your Client connection code, such as updating the namespace and gRPC endpoint.
+You'll use:
+
+- The [Temporal Cloud Namespace Id](https://docs.temporal.io/cloud/namespaces#temporal-cloud-namespace-id).
+- The [Namespace's gRPC endpoint](https://docs.temporal.io/cloud/namespaces#temporal-cloud-grpc-endpoint).
+  The endpoint uses this format `(namespace.unique_id.tmprl.cloud:port)`.
+- [Paths to the SSL certificate (.pem) and private key (.key)](https://docs.temporal.io/cloud/saml#integrate-saml-with-your-temporal-cloud-account) registered to your Namespace and stored on your Worker's file system.
+
+Copy the Namespace Id and the gRPC endpoint from the Namespace detail Web page on [Temporal Cloud Namespaces](https://cloud.temporal.io/namespaces). Click on a Namespace name to open the Namespace details.
 
 ### Run a Self-hosted Worker {#dockerfile}
 
@@ -667,7 +673,9 @@ Copy the IP address part.
 Set IP address, port, and Namespace in the Temporal Client options.
 
 <!--SNIPSTART setup-chapter-worker-self-hosted-->
+
 [docs/tutorials/go/background-check/code/setup/self_hosted_worker/main.go](https://github.com/temporalio/temporal-learning/blob/main/docs/tutorials/go/background-check/code/setup/self_hosted_worker/main.go)
+
 ```go
 package main
 
@@ -709,8 +717,8 @@ func main() {
 		log.Fatalln("Unable to start the Worker Process", err)
 	}
 }
-
 ```
+
 <!--SNIPEND-->
 
 #### Build and deploy Docker image {#dockerfile}
@@ -932,14 +940,15 @@ You should now be at [http://localhost:8080/namespaces/backgroundcheck_namespace
 
 ## Add a testing framework {#test-framework}
 
-
 **How to add a Testing Framework and Tests for the Workflow and Activity.**
 
 Each Temporal SDK has a testing suite that can be used in conjunction with a typical language specific testing framework.
-In the Temporal Go SDK, the `testsuite` package (https://pkg.go.dev/go.temporal.io/sdk/testsuite)  provides a test environment in which the Workflow and Activity code may be run for test purposes.
+In the Temporal Go SDK, the `testsuite` package (https://pkg.go.dev/go.temporal.io/sdk/testsuite) provides a test environment in which the Workflow and Activity code may be run for test purposes.
 
 <!--SNIPSTART setup-chapter-test-framework-->
+
 [docs/tutorials/go/background-check/code/setup/tests/backgroundcheckboilerplate_test.go](https://github.com/temporalio/temporal-learning/blob/main/docs/tutorials/go/background-check/code/setup/tests/backgroundcheckboilerplate_test.go)
+
 ```go
 package setup
 
@@ -967,16 +976,15 @@ func Test_BackgroundCheckApplication(t *testing.T) {
 	s := &UnitTestSuite{}
 	suite.Run(t, s)
 }
-
 ```
+
 <!--SNIPEND-->
 
 In this example, we use a custom struct that absorbs both the testing functionality from testify (https://pkg.go.dev/github.com/stretchr/testify/suite) via `suite.Suite` and the testing functionality from the Temporal test framework via `testsuite.WorkflowTestSuite`.
 Next we create a regular test function recognized by the `go test` command, and pass an instance of the struct to `suite.Run`.
 
 ### Add Workflow function tests {#test-workflow-code}
 
-
 We can test Workflow code for the following conditions:
 
 - Workflow status. For example, did the Workflow reach a completed status?
@@ -987,9 +995,10 @@ We can test Workflow code for the following conditions:
 We can also perform a Workflow Replay test, and we'll provide detailed coverage of this topic in another section.
 
 <!--SNIPSTART setup-chapter-test-workflow-->
+
 [docs/tutorials/go/background-check/code/setup/tests/backgroundcheckboilerplate_test.go](https://github.com/temporalio/temporal-learning/blob/main/docs/tutorials/go/background-check/code/setup/tests/backgroundcheckboilerplate_test.go)
-```go
 
+```go
 const ssn string = "555-55-5555"
 
 // Test_BackgroundCheckWorkflow tests the BackgroundCheck Workflow function
@@ -1013,8 +1022,8 @@ func (s *UnitTestSuite) Test_BackgroundCheckWorkflow() {
 	s.NoError(env.GetWorkflowResult(&result))
 	s.Equal(result, ssnTraceResult)
 }
-
 ```
+
 <!--SNIPEND-->
 
 Calling `env.ExecuteWorkflow(...)` executes the Workflow logic and any invoked Activities inside the test process.
@@ -1036,9 +1045,10 @@ We can test Activity code for the following conditions:
 - Activity return values. Check to ensure the return value is expected.
 
 <!--SNIPSTART setup-chapter-test-activity-->
+
 [docs/tutorials/go/background-check/code/setup/tests/backgroundcheckboilerplate_test.go](https://github.com/temporalio/temporal-learning/blob/main/docs/tutorials/go/background-check/code/setup/tests/backgroundcheckboilerplate_test.go)
-```go
 
+```go
 // Test_SSNTraceActivity tests the SSNTraceActivity function
 func (s *UnitTestSuite) Test_SSNTraceActivity() {
 	// Create a test environment
@@ -1055,6 +1065,6 @@ func (s *UnitTestSuite) Test_SSNTraceActivity() {
 	// Check for the expected return value.
 	s.Equal("pass", result)
 }
-
 ```
+
 <!--SNIPEND-->