Skip to content

Worker: Fix dataclip serialization - #1507

Merged
josephjclark merged 6 commits into
release/nextfrom
improve-dataclip-serializing
Aug 26, 2026
Merged

Worker: Fix dataclip serialization#1507
josephjclark merged 6 commits into
release/nextfrom
improve-dataclip-serializing

Conversation

@josephjclark

Copy link
Copy Markdown
Collaborator

Short Description

This PR adds an option to remove the stringifying of dataclips before they're sent to Lightning.

I'm certain this was added in error in the very first implementation and never looked at again.

But it's causing dataclips send to lightning to bloat over the allowed frame limit, causing large dataclips to trigger lost runs.

See matching Lightning PR for more details: OpenFn/lightning#5098
A one or two-sentence description of what this PR does.

Fixes #1504

This is branched on top of some general diagnostics and sentry improvements.

AI Usage

Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):

  • I have used Claude Code
  • I have used another model
  • I have not used AI

You can read more details in our
Responsible AI Policy

@github-project-automation github-project-automation Bot moved this to New Issues in Core Aug 26, 2026
@josephjclark
josephjclark changed the base branch from main to fix-sentry-reporting August 26, 2026 10:48
@josephjclark

Copy link
Copy Markdown
Collaborator Author

I'd like to confirm lightning version before merging

Base automatically changed from fix-sentry-reporting to release/next August 26, 2026 14:34
josephjclark and others added 6 commits August 26, 2026 15:36
Each run already opened a sentry isolation scope, but engine and socket
callbacks fire outside its async context, so breadcrumbs and errors were
landing on the global scope and interleaving across concurrent runs. The
scope is now held on the run context and re-entered where the reporting
actually happens.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…IFY_STATE

The worker double-JSON-encodes step output dataclips before sending them to
Lightning: once via a manual stringify, then again when phoenix serializes
the envelope. That double-encoding is what bloats large dataclips past
Lightning's websocket frame limit and kills the connection mid-run. The
runtime already sanitizes/clones state before it reaches this point, so the
manual stringify is redundant - but skipping it changes the wire format, so
it's opt-in via --stringify-state/--no-stringify-state (CLI) or
WORKER_NO_STRINGIFY_STATE (env), default false to preserve current
behaviour until the matching Lightning-side support (2.19+) is widely
deployed.
@josephjclark
josephjclark force-pushed the improve-dataclip-serializing branch from 7c5eee5 to fcb4846 Compare August 26, 2026 14:54
@josephjclark

Copy link
Copy Markdown
Collaborator Author

Looks good. This produces correct dataclip with:

  • this branch and main lightning
  • this branch and lightning branch with default settings (double encoding) - works great
  • this branch and lightning branch with encoding off (the fix) - works great

@josephjclark
josephjclark merged commit c433bcf into release/next Aug 26, 2026
10 checks passed
@josephjclark
josephjclark deleted the improve-dataclip-serializing branch August 26, 2026 15:17
@github-project-automation github-project-automation Bot moved this from New Issues to Done in Core Aug 26, 2026
josephjclark added a commit that referenced this pull request Aug 27, 2026
* Worker: better reporting on socket errors (#1505)

* Worker: attribute sentry reports to the run that produced them

Each run already opened a sentry isolation scope, but engine and socket
callbacks fire outside its async context, so breadcrumbs and errors were
landing on the global scope and interleaving across concurrent runs. The
scope is now held on the run context and re-entered where the reporting
actually happens.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* carry payload size on step-complete events for better reporting

* type fix

* add payload size to step complete event

* report payload size to sentry

* changeset

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Worker: Fix dataclip serialization (#1507)

* Worker: attribute sentry reports to the run that produced them

Each run already opened a sentry isolation scope, but engine and socket
callbacks fire outside its async context, so breadcrumbs and errors were
landing on the global scope and interleaving across concurrent runs. The
scope is now held on the run context and re-entered where the reporting
actually happens.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* carry payload size on step-complete events for better reporting

* type fix

* report better errors out of sentry

* Gate double-encoding fix for output dataclips behind WORKER_NO_STRINGIFY_STATE

The worker double-JSON-encodes step output dataclips before sending them to
Lightning: once via a manual stringify, then again when phoenix serializes
the envelope. That double-encoding is what bloats large dataclips past
Lightning's websocket frame limit and kills the connection mid-run. The
runtime already sanitizes/clones state before it reaches this point, so the
manual stringify is redundant - but skipping it changes the wire format, so
it's opt-in via --stringify-state/--no-stringify-state (CLI) or
WORKER_NO_STRINGIFY_STATE (env), default false to preserve current
behaviour until the matching Lightning-side support (2.19+) is widely
deployed.

* docs and changelog

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

* versions

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

Large dataclips can still cause runs to be lost

2 participants