release: v1.1.8 — fix worker workspaces booting without openflows-harness - #144
Merged
Conversation
…ness The v1.1.6 and v1.1.7 GitHub releases that worker templates (forge, sentinel, vessel, lore) download openflows-harness from no longer exist (likely removed after creation), so the pinned-version curl download in every worker's startup_script has been silently 404ing. The script logs a WARNING and continues, so workspaces boot with no harness binary and get handed ticket dispatch anyway (observed on T-047, T-048 sentinel sessions). - Bump binary/Cargo.toml to 1.1.8 so the release workflow builds and publishes a fresh openflows-harness binary under this tag. - Bump harness_version default in all four worker templates (openflows-forge, openflows-sentinel, openflows-vessel, openflows-lore) from 1.1.6 to 1.1.8 so newly provisioned workspaces download the binary that will actually exist after this release ships. Follow-up (not in this commit): make the startup_script fail hard (or block ticket dispatch) instead of warning-and-continuing when the harness download fails, so this class of silent-degradation can't recur.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
Nexus-AgentFlow
approved these changes
Aug 6, 2026
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
2 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.
Problem
Worker workspaces (Sentinel, Forge, Vessel, Lore) are booting with no
openflows-harnessbinary and being handed ticket dispatch anyway. Observed directly on the T-047 and T-048 Sentinel sessions —openflows-harness: not foundfor every subcommand.Root cause
gh release list --repo The-AgenticFlow/openflowsreturns zero releases, andgh api repos/.../releasesconfirms it ([]).v1.1.7(id342816806) was successfully created and had all platform tarballs uploaded on 2026-06-22 (confirmed via the archivedCreate Releasejob log), but it no longer exists via the API — it was removed at some point after creation.startup_script(crates/coder-client/templates/openflows-{forge,sentinel,vessel,lore}/main.tf) downloads the harness binary from a pinned-version GitHub release tarball URL. With no release present, thatcurl404s.WARNING: Failed to download openflows-harness — agent will not be able to coordinateand continues — the workspace boots successfully with the harness missing, and nothing downstream checks for this before assigning work.Fix in this PR
binary/Cargo.tomlversion1.1.6→1.1.8so theReleaseworkflow (triggered by thev1.1.8tag push after this merges) builds and publishes a freshopenflows-harnessbinary.harness_versiondefault in all four worker templates from1.1.6→1.1.8so newly provisioned workspaces point at the release that will actually exist.Not in this PR (tracked as follow-up)
The silent-degradation behavior itself — worker templates warning-and-continuing instead of failing hard (or blocking ticket dispatch) when the harness download fails — is the systemic issue that let this go unnoticed. That hardening is a separate change and is intentionally not bundled into this release-unblocking fix.
Verification
cargo check -p openflowspasses with the version bump;coder-client's build script regenerates the Coder template archives from the updated.tfsources.v1.1.8and pushing the tag will trigger.github/workflows/release.yml, which buildsopenflows-harnessforx86_64-unknown-linux-musl(the platform the templates fetch) among others, and publishes the GitHub Release the templates'curlcall depends on.