Prior to version 3.1.0 of opscotch, payload manipulation was limited to text - you could manipulate that at the byte level in JavaScript but it was very cumbersome and inefficient.

Version 3.1.0 of opscotch adds a ByteContext plus a ByteReader for low-level byte manipulation inside workflows. This is for engineers who already think in buffers, encodings, and compression.

Version 3.1.0 of opscotch adds error-handling helpers to the JavaScript context. You can now flag user-facing errors, capture system errors, and check whether a context (including one returned from sendToStep) is in an error state.

The goal: make signing, encryption, hashing, and random bytes straightforward without leaving JavaScript processors. Version 3.1.0 of opscotch introduces a CryptoContext that brings libsodium-grade primitives into workflows. It works with ByteContext, so everything is buffers (not strings).

Version 3.1.0 of opscotch adds support for HTTP multipart uploads, letting you receive text/JSON and binary content in the same request. This unlocks use cases like “send me the metadata and the file in one hit,” without forcing you to pick one or chain requests. With saftey in mind - this is disabled by default.

Version 3.1.0 adds OpenTelemetry support so opscotch can join your existing traces. Enable it with an environment variable and annotate traces from JavaScript processors.

Version 3.1.0 of opscotch adds two big improvements for handing work to other steps: a new JavascriptStateContext for reading results and errors, and sendToStepAndForget(...) for fire-and-forget concurrency.

In opscotch version 3, file access was introduced, along with the fileWatcher step trigger. File watching is a capability that allows you to request the agent to call a step when a file is changed—for example, when a log file is updated, you can receive the new lines as a step payload. As security is always a top priority, file access is strictly controlled in several ways.

An exciting change in version 3 of opscotch is the introduction of workflow-available high-performance persistent FIFO queues. This was the missing functionality that allows opscotch workflows to robustly buffer outbound data - essentially acting as a log aggregator, among other uses.

In opscotch workflows, by default, a step can be run at any time, even if there is already a run on that step — meaning this step can be executed in multiple threads. But what if you want to enforce single-threaded execution for a step?

With the addition in version 3 of file access and HTTP listening (you should read those blog posts first), the combination of these two features allows for serving static content, i.e., images, HTML, JavaScript, etc., from opscotch. As security is always a top priority, HTTP requests for static content are strictly controlled in several ways.