Skip to content

docs(typescript): snipsync hand-copied code blocks; drop unpublished GCP OTel content - #5024

Closed
lennessyy wants to merge 3 commits into
mainfrom
typescript-snipsync-markers
Closed

docs(typescript): snipsync hand-copied code blocks; drop unpublished GCP OTel content#5024
lennessyy wants to merge 3 commits into
mainfrom
typescript-snipsync-markers

Conversation

@lennessyy

@lennessyy lennessyy commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

Three independent changes, one commit each.

1. Snipsync twelve hand-copied blocks (c6bc8f8)

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. This wraps the twelve 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)

Depends on temporalio/samples-typescript#504, which adds the six standalone-activity markers. No strict merge order: snipsync only splices IDs it can resolve, so until #504 lands those blocks stay as-is rather than emptying. The other six markers already exist on main.

Rather than hand-checking the output 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 is a no-op here.

Two incidental fixes on standalone-activities.mdx: it carried hand-written source-link lines that snipsync generates itself, and its fences said typescript where snipsync emits ts.

2. Drop unpublished GCP OpenTelemetry content (8791a44)

The Cloud Run pages documented a GCP OpenTelemetry plugin that does not exist. sdk-go/contrib/gcp and sdk-python's temporalio/contrib/gcp both 404 on main, and gcp_open_telemetry/ is absent from samples-python — so four snipsync IDs on these pages resolve nowhere and the code shown cannot be run. The samples are weeks out.

Removes 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, 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. Keeps the three pages parallel and preserves the #add-observability anchor.

Also drops two stale "add the OpenTelemetry plugin to the Worker" lead-ins from the deployment guide's Python and Go tabs. Those sentences carried the tabs' only links to their SDK pages, so the links are kept and reworded to match the TypeScript tab. Python's serverless index and page keywords advertised the plugin where its Go and TypeScript siblings did not; both now match.

3. Link the first Temporal Client reference (235b1596)

Four pages in this branch mentioned a Temporal Client without linking anywhere. Each now links its first reference to that SDK's Temporal Client page: the Go and Python Cloud Run pages (in "Configure the Temporal connection"), standalone-activities.mdx (opening paragraph), and set-up.mdx (step 4, where the reader creates the Client). The other three pages in the branch don't mention a Temporal Client.

Verification

yarn build passes. CI-scoped Vale is clean on all changed files (3 suggestions, all pre-existing headings). All ten new source-link URLs return 200. yarn check-links reports failures spread evenly across every sample directory in the repo including untouched ones — GitHub 429 rate limiting, not attributable to this change.

🤖 Generated with Claude Code

┆Attachments: EDU-6877 docs(typescript): snipsync hand-copied code blocks; drop unpublished GCP OTel content

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`.
…ages

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.
@lennessyy
lennessyy requested a review from a team as a code owner August 3, 2026 21:26
@vercel

vercel Bot commented Aug 3, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
temporal-documentation Ready Ready Preview Aug 3, 2026 9:42pm

Request Review

@github-actions

github-actions Bot commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

📖 Docs PR preview links

Four of the pages in this branch mention a Temporal Client without
linking anywhere, leaving a reader who does not already know the term
with no next step.

Link the first reference on each to that SDK's Temporal Client page:

- go and python Cloud Run pages, in "Configure the Temporal connection"
- typescript standalone-activities.mdx, in the opening paragraph
- typescript set-up.mdx, at step 4 where the reader creates the Client

The other three pages in the branch do not mention a Temporal Client.
@lennessyy

Copy link
Copy Markdown
Contributor Author

I will do this together with #5001

@lennessyy lennessyy closed this Aug 3, 2026
lennessyy added a commit that referenced this pull request Aug 3, 2026
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.
lennessyy added a commit that referenced this pull request Aug 3, 2026
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.
lennessyy added a commit 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>
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.

1 participant