docs(standalone-activity): add snipsync markers for the docs page - #504
Open
lennessyy wants to merge 1 commit into
Open
docs(standalone-activity): add snipsync markers for the docs page#504lennessyy wants to merge 1 commit into
lennessyy wants to merge 1 commit into
Conversation
The TypeScript Standalone Activities docs page carries ten inline code blocks copied by hand from this sample, so nothing catches drift between the two. They have already diverged in wording. Add markers around the six regions the docs reproduce verbatim: - activities.ts and worker.ts (whole file) - the start call, result fetch, and getHandle call in execute.ts - the count call in list.ts The remaining four docs blocks are not marked. Two merge non-adjacent regions of execute.ts, and snipsync inserts a literal `// ...` at each seam; a third needs `id: activityId` where the sample must use a suffixed id to avoid a collision within its single run; the fourth spans the query and the list loop, which list.ts separates with the count call. Marking those would mean reshaping the sample around the docs. Comment-only change. Build, lint, and prettier pass.
lennessyy
added a commit
to temporalio/documentation
that referenced
this pull request
Aug 3, 2026
The TypeScript SDK guide has 217 inline TS/JS code blocks and none of them were snipsynced, so nothing catches drift from the samples they were copied from. Wrap the twelve blocks whose content is already byte-identical to a marker in samples-typescript: - versioning.mdx: the four patching blocks (patching-api) - set-up.mdx: the greet Activity and example Workflow (hello-world) - standalone-activities.mdx: six blocks (standalone-activity) The six standalone-activity markers are added in temporalio/samples-typescript#504. Until that merges these blocks stay as-is; snipsync only splices IDs it can resolve, so an unmatched ID is left untouched rather than emptied. Rather than hand-checking the format, each block was verified against snipsync's own output, reproduced by driving its deindentByCommonPrefix over the real sample files. All twelve match byte-for-byte, so the next yarn snipsync run is a no-op here. Two incidental fixes fall out on standalone-activities.mdx: it had hand-written source-link lines that snipsync generates itself, and its fences said `typescript` where snipsync emits `ts`.
lennessyy
added a commit
to temporalio/documentation
that referenced
this pull request
Aug 3, 2026
* Restructure the Java, .NET, Ruby, and Rust Worker pages Gives all four pages the same six sections as the Go, Python, and TypeScript pages: create and run, register types, connect to Cloud, configure options, run a versioned Worker, shut down. - Adds a versioned Worker section. None of these pages documented Worker Versioning. - Replaces hand-written code with snipsync snippets for Java, .NET, and Ruby. Rust stays inline because the features repo has no Rust harness. - Notes that a versioning behavior only applies on a Worker with versioning enabled. Declaring one without it makes the server reject the Workflow Task. - Rewrites the Rust page against temporalio-sdk 0.5.0. The previous code used execute_activity, which only exists on the SDK's unreleased main branch, and omitted the ? that register_workflow requires. Existing anchor IDs are preserved because other pages link to them. Every Worker was run against a local dev server and completed a Workflow. Snippet bodies for Java, .NET, and Ruby come from temporalio/features#861 and need that PR merged before the next snipsync run. * Fix reader-path issues on the four Worker pages - .NET: the shutdown section referred to "the token passed to ExecuteAsync()" when the reader had only ever passed CancellationToken.None. Shutting a Worker down is a start-time decision in .NET, so the section now shows creating a CancellationTokenSource and passing its Token, and the first section explains what CancellationToken.None does instead of only warning against it. - Rust: move the Cargo.toml dependencies ahead of the code that needs them, and rename "Register types" to match the other pages. The anchor comment sets the heading id, so #register-types is unchanged. - Ruby: tighten the run_all description, and move the shutdown_signals and cancellation details into the shutdown section rather than forward-referencing them from the first section. * Fix reader-path issues on the Go, Python, and TypeScript Worker pages Follow-up to #4980, applying the same pass done for the other four SDKs. - Python: the shutdown snippet used interrupt_event, which the page never defined. The SNIPSTART boundary in the features repo excludes the enclosing function that declares it. Adds the entry point that sets the event. - Python: run() installs no signal handlers and polls until shutdown() is called, so "the Worker runs until the process is interrupted" was inaccurate. - TypeScript: lowercase the operating system signals. Signal is a Temporal core term, so the capitalized form read as a Workflow Signal. - TypeScript: drop the paragraph in the first section that restated the registration rule the next section already states, and document per-Workflow versioningBehavior through setWorkflowOptions. - Go: document DefaultVersioningBehavior, that it requires UseVersioning, and that a Workflow with no behavior fails at registration time. - Go: name the Worker instead of "It" in the shutdown section. * Correct the registration claim and cut hedging language The registration section on all seven pages said a Task for an unregistered type fails and "The Workflow Execution itself does not fail." The second half holds for Workflow Tasks but not Activity Tasks: sdk-go fails an unregistered Activity Task deliberately so it retries, and exhausting the Activity's Retry Policy can fail the Workflow. Drops that claim and states up front that a Task Queue does not route by type, which is why the same-registration rule exists at all. Removes the .NET dependency injection section. Temporalio.Extensions.Hosting is a separate package, DI there applies to Activities and never to Workflows, and the section implied otherwise by registering a Workflow in the same chain. Nothing linked to the anchor. Cuts hedging from the TypeScript page, most of it in the older Docker content: "you might want to," "it is generally possible," "we recommended," "it's probably because." Two of those hid the actual fact. The Node.js memory default is wrong in Docker because it reads the host's memory rather than the container limit, and a distroless build fails outright because npm is absent, rather than "might result in various error messages." * Link the first Temporal Client reference on each Worker page Every Worker page opens by telling the reader to create a Worker with a Temporal Client, but none of them linked the term, so a reader who does not already have a Client had no next step. Each page did link the Client page later, from "Connect to Temporal Cloud", which is the wrong place to first meet the concept. Link the first reference on each page to that SDK's Temporal Client page. Java said "Workflow Client" here; that is the class name, not the documented term, so it now reads "Temporal Client" like the other pages. Rust had the term only as a bare `Client` code span, which mapped to the code but not to the concept. The TypeScript page is left alone. `Worker.create()` takes a NativeConnection rather than a Client, so the page has no Temporal Client reference to link, and saying otherwise would be wrong. * docs(serverless): drop GCP OpenTelemetry content from the Cloud Run pages The Cloud Run pages documented a GCP OpenTelemetry plugin that does not exist yet. sdk-go/contrib/gcp and sdk-python temporalio/contrib/gcp both 404 on main, and gcp_open_telemetry/ is absent from samples-python, so the four snipsync IDs on these pages resolve nowhere and the code shown cannot be run. The samples are weeks out. Remove the plugin sections from the Go and Python Cloud Run pages, including the shutdown-flush subsection and the 70-line collector config. In their place keep the generic "Add observability" section the TypeScript page already carries: a Cloud Run Worker emits the same telemetry as any other Worker, which is true independent of the plugin. This keeps the three pages parallel and preserves the #add-observability anchor. Also drop the two stale "add the OpenTelemetry plugin to the Worker" lead-ins from the deployment guide's Python and Go tabs, keeping the links to the SDK pages and matching the TypeScript tab's wording. Python's serverless index and page keywords advertised the plugin where its Go and TypeScript siblings did not; both now match. * Link the Temporal Client reference on the Cloud Run pages Matches the Worker pages: the Go and Python Cloud Run pages first mention a Temporal Client in "Configure the Temporal connection" without linking it. Moved here from #5024 along with the OpenTelemetry removal, so that only one PR touches these two files. * docs(typescript): snipsync twelve hand-copied code blocks The TypeScript SDK guide has 217 inline TS/JS code blocks and none of them were snipsynced, so nothing catches drift from the samples they were copied from. Wrap the twelve blocks whose content is already byte-identical to a marker in samples-typescript: - versioning.mdx: the four patching blocks (patching-api) - set-up.mdx: the greet Activity and example Workflow (hello-world) - standalone-activities.mdx: six blocks (standalone-activity) The six standalone-activity markers are added in temporalio/samples-typescript#504. Until that merges these blocks stay as-is; snipsync only splices IDs it can resolve, so an unmatched ID is left untouched rather than emptied. Rather than hand-checking the format, each block was verified against snipsync's own output, reproduced by driving its deindentByCommonPrefix over the real sample files. All twelve match byte-for-byte, so the next yarn snipsync run is a no-op here. Two incidental fixes fall out on standalone-activities.mdx: it had hand-written source-link lines that snipsync generates itself, and its fences said `typescript` where snipsync emits `ts`. * Link the Temporal Client reference on two TypeScript pages standalone-activities.mdx mentions a Temporal Client in its opening paragraph, and set-up.mdx introduces one at step 4 where the reader creates it. Neither linked the term. Moved here from #5024 with the rest of that branch. --------- Co-authored-by: Duncan Mackenzie <duncanma@duncanmackenzie.net>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The TypeScript Standalone Activities docs page carries ten inline code blocks copied by hand from this sample, so nothing catches drift between the two. They have already diverged: the docs say "business identifier" where
execute.tssays "business ID", and they strip theasync function run()wrapper.This adds markers around the six regions the docs reproduce verbatim:
typescript-standalone-activity-definitionactivities.ts(whole file)typescript-standalone-activity-workerworker.ts(whole file)typescript-standalone-activity-startexecute.tstypescript-standalone-activity-resultexecute.tstypescript-standalone-activity-get-handleexecute.tstypescript-standalone-activity-countlist.tsComment-only change, 12 lines. No behavior change.
Why only six of ten
The other four docs blocks are deliberately left unmarked, because marking them would degrade the rendered page:
executecall merge non-adjacent regions ofexecute.ts.selectedLineshandles non-contiguous ranges, but snipsync inserts a literal// ...at each seam, and because the imports sit at column 0 the common-prefix dedent computes to empty, so the function body would render indented under flush-left imports.executeblock needsid: activityId, but the sample must use a suffixed id to avoid an Activity Id collision inside its single run.list.tsseparates with the count call.Fixing those means reshaping the sample around the docs, which doesn't seem like the right trade.
Verification
npm run build,npm run lint, andprettier --checkall pass onstandalone-activity. No new duplicate marker IDs.On the docs side I reproduced snipsync's output for all six markers (driving its own
deindentByCommonPrefix) and confirmed each matches the current page content byte-for-byte, so the firstyarn snipsyncafter this merges is a no-op rather than a surprise rewrite.Docs-side PR: temporalio/documentation#5024