Temporal's standalone activities hit GA as n8n hardens its core

Standalone activities become the default

The headline of the week is Temporal Server v1.32.0, which promotes Standalone Activities and start delay to general availability — both now enabled out of the box via activity.enableStandalone and activity.startDelayEnabled. The practical shift for developers is that activities no longer have to live inside a workflow's control flow to be scheduled, retried, or observed: you can start an activity on its own, delay its execution, and manage it as a first-class object.

The more interesting addition is the operator surface. With history.enableStandaloneActivityOperatorCommands: true, operators can pause or resume a running activity, reset its attempt state (optionally with heartbeat cleanup or restoration of the original options), and update individual options or roll them back. That's a meaningful change to how you handle a misbehaving activity in production — previously your options were often to wait it out or restart the surrounding workflow. Batch operations round out the release, which suggests Temporal is targeting the fleet-management case, not just single-activity surgery.

n8n's week is a stability grind

n8n's output this week was voluminous but mostly corrective, spread across the 2.39, 2.38, 2.37, and 1.123 lines. The 2.39 branch opened with n8n@2.39.0 and n8n@2.38.0 landing the same day; the former fixed an AMQP trigger node that failed to reattach its receiver link when the broker detached it — a classic silent-stall bug for anyone relying on AMQP to enqueue work.

From there, the week's theme is reliability under adverse conditions. n8n@2.38.4 and n8n@2.37.11 both addressed keeping a serving external secrets provider alive when its replacement fails, plus cleanup of running jobs when a workflow run rejects. n8n@2.38.5 tackled error fidelity — the original job error is now reported even after the job key disappears, which matters when you're debugging from logs alone.

Memory and shutdown behavior got attention too. n8n@2.38.6 bounds peak memory during source control pushes, and n8n@2.38.7 fixed executing MCP toolkit members on workers. On the 2.39 line, n8n@2.39.1 repairs legacy-format data-encryption keys during bootstrap, while n8n@2.39.2 memoizes pairedItem ancestry traversal — a perf fix with real payoff in large item-heavy workflows. Later in the week, n8n@2.39.3 trusts the CA from GIT_SSL_CAINFO for source control HTTPS remotes, and n8n@2.39.4 selects sandbox npm install flags by provider. n8n@1.123.79 closed out the older line with no changes of note.

If you run n8n in production, the 2.38.4/2.37.11 pair is the one to prioritize — secrets provider failover and job cleanup on rejection are both failure-mode fixes you don't want to learn about the hard way.