Checkout project yaml rebase - #1545
Closed
josephjclark wants to merge 19 commits into
Closed
Conversation
joinRunChannel awaited sendEvent(GET_PLAN) inside an unguarded async callback, so a rejection (now possible since Lightning can reply an error to fetch:plan for adaptor resolution failures) became an unhandled rejection instead of settling the outer promise. The worker's local capacity slot for that run leaked until restart. Wrap the await in try/catch and reject, mirroring the existing error/timeout branches in the same file.
* 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 * Workflow: add remove()/isRemoved() to flag removed steps, edges and workflows Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Project: generate delete: true entries from Workflow.removed in to-app-state Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix an issue where removing a workflow with history triggers an error * fix remove workflow * clean up comments * hydrate deleted state * update changeset * mock: support for deletes * test for removing workfow * mock: seed version history * update deploy test * changeset * remove dupe test * remove another dupe * remove another dupe * again --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Several things wrong
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…deploy Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* attempt to fix a deploy to an existing project * fix an issue where the wrong alias gets updated
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
3 participants
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.
Short Description
This PR adds CLI support to deploy a v1 project.
The base PR adds support for project v2 only, on the assumption that the app is standardising on exporting projects in the v2 style.
But that assumption doesn't work: production still uses v1 formats. So it's probably worth adding this support in, otherwise the feature is kind of usable for one of its major use-cases
Implementation Details
This is a bigger PR than I expected because it makes a change that was probably inevitable.
At the moment, there's a buch of condition logic in
to-app-stateused to serialize a statefile as as v1 spec file. This was pretty horrible really.This PR splits that logic out in to
to-app-specandfrom-app-spec.That's how we support the 1 file on deploy: we load a v1 spec as a Project, and then simply deploy it with the regular means.
AI Usage
Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):
You can read more details in our
Responsible AI Policy