Skip to content

chore: update @flue/* + tooling to beta.9, migrate to new runtime API#2

Merged
ephor merged 12 commits into
LingoVerse:mainfrom
lapa2112:chore/update-flue-deps
Jul 2, 2026
Merged

chore: update @flue/* + tooling to beta.9, migrate to new runtime API#2
ephor merged 12 commits into
LingoVerse:mainfrom
lapa2112:chore/update-flue-deps

Conversation

@lapa2112

@lapa2112 lapa2112 commented Jul 1, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Bumps @flue/runtime and @flue/cli 1.0.0-beta.2/beta.1beta.9 (plus valibot, @types/node, oxfmt, oxlint) and migrates the code to the breaking beta.9 API.
  • Workflows now use export default defineWorkflow({ agent, input, run }) with an ActionContext-typed handler instead of export async function run + FlueContext<Payload>; harness comes from context instead of await init(agent). The passthrough route export is kept — it still gates POST /workflows/:name.
  • Payload interfaces became valibot schemas (used as each workflow's input schema); inferred types are re-exported for the channel.
  • defineTool: parameters/executeinput/run({ input }); tests updated to match.
  • log.ts uses the now-exported FlueLogger type directly.
  • post-review.ts: interface PostResulttype (needed for JSON-assignability under the new API).
  • @flue/github stays at beta.1 — it's the only published version and has no dependency on @flue/runtime.
  • Also re-ran the bumped oxfmt across the repo (formatting-only diffs in README, channels/github.ts, lib/retry.ts, workflows/admin.ts).

Test plan

  • bun run typecheck — clean
  • bun run lint (oxlint) — clean
  • bun run test — 76/76 pass (on Node 22.23.1; repo's engines requires >=22.19.0)
  • Manually verified the channel→workflow HTTP contract still holds: POST /workflows/:name treats the raw JSON body as input (no { input } wrapping), matching what src/channels/github.ts sends.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the codebase to align with the latest @flue/runtime API (v1.0.0-beta.9). Key changes include upgrading dependencies, migrating workflow and agent definitions to use defineWorkflow and defineAgent, replacing TypeScript interfaces with Valibot schemas for payload validation, and updating tool definitions to use input and run instead of parameters and execute. There are no review comments, so I have no feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

Bump @flue/runtime and @flue/cli 1.0.0-beta.2/beta.1 → beta.9 (plus
valibot, @types/node, oxfmt, oxlint) and migrate to the breaking
beta.9 API:

- Workflows: `export async function run` + `FlueContext<Payload>` →
  `export default defineWorkflow({ agent, input, run })` with an
  `ActionContext`-typed handler; harness now comes from context instead
  of `await init(agent)`. The passthrough `route` export is kept (it
  still gates POST /workflows/:name).
- Payload interfaces → valibot schemas (used as each workflow's `input`
  schema); inferred types re-exported for the channel.
- defineTool: `parameters`/`execute` → `input`/`run({ input })`; tests
  updated accordingly.
- log.ts uses the now-exported `FlueLogger` type directly.
- post-review.ts: `interface PostResult` → `type` (JSON-assignable).

@flue/github stays at beta.1 (its only published version; no runtime
dep). Also re-ran the bumped oxfmt across the repo (formatting only in
README, channels/github, lib/retry, workflows/admin).

typecheck + oxlint clean; 76/76 tests pass on Node 22.23.1.
@lapa2112 lapa2112 force-pushed the chore/update-flue-deps branch from 6700622 to 5a7146e Compare July 1, 2026 16:14
lapa2112 added 5 commits July 1, 2026 20:03
…move admin to app.ts

- channel admits review/remember/feedback runs via ambient invoke() instead of a
  loopback HTTP self-POST; removes INTERNAL_BASE_URL and the loopback guard
- workflows no longer export `route` — closes the unauthenticated POST
  /workflows/* endpoints (could trigger reviews / burn tokens on any repo the
  GITHUB_TOKEN can read)
- admin dashboard moves from workflows/admin.ts to a GET /admin app route
  (was spuriously generating a Durable Object class on the Cloudflare target)
- validateEnv failure throws instead of process.exit(1) (works on workerd too)
- store interface is now async; SqliteDedupStore (node:sqlite) becomes the Node
  backend and a new D1Store the Cloudflare backend, selected at runtime by a
  `#app-store` subpath import (workerd condition) — one codebase, two targets
- add wrangler.jsonc (Durable Object migrations for the generated workflow
  classes + D1 binding), migrations/0001_init.sql, .dev.vars.example, CF scripts
- agents (Agents SDK) as an optionalDependency; wrangler, workers-types and
  vitest-pool-workers as dev deps. D1 backend tested in workerd (bun run test:cf)
- optional ADMIN_TOKEN gate on GET /admin (the Worker URL is public)
- oxfmt: ignore wrangler.jsonc (it kept rewriting JSONC trailing commas)
- docs: DEPLOY.md Cloudflare section (D1 create + migrate + secrets + deploy) and
  README storage/target notes

Node/Docker stays the recommended path and is unchanged in behavior.
getCloudflareContext() is only in scope inside Flue's dispatched work (Durable
Objects), not in the main-worker Hono routes — the GitHub channel handler and the
/admin route. Both resolved the D1 store via getCloudflareContext() and threw
"Not running in a Cloudflare context" (500 on /admin; would also break the
channel's claim() on the first real webhook).

Resolve the binding from c.env.DB in those paths and thread it through the store
factory (getDedupStore/getReviewRunStore accept an optional binding). Node (no
c.env.DB) and DO-run workflow code (where getCloudflareContext works) are
unaffected. Verified on the deployed Worker: GET /admin -> 200.
@lapa2112 lapa2112 marked this pull request as ready for review July 1, 2026 22:51
ephor
ephor previously approved these changes Jul 2, 2026
The Pull requests: write requirement was easy to miss — reviews run but the post
silently 403s. Make it a callout in §2b + prerequisites, add the exact symptom to
troubleshooting, require Issue comments for /review, and note fine-grained-PAT
permission edits keep the same token value (no secret re-set).
lapa2112 added 5 commits July 2, 2026 13:03
…bot])

lib/github.ts uses createAppAuth (@octokit/auth-app) when GITHUB_APP_ID +
GITHUB_APP_PRIVATE_KEY + GITHUB_APP_INSTALLATION_ID are set — comments then carry
the bot identity and badge — and falls back to GITHUB_TOKEN (PAT) otherwise.
validateEnv now requires exactly one of the two auth modes. Builds for both node
and workerd (universal-github-app-jwt v2 uses Web Crypto). Docs and env examples
updated; DEPLOY.md §2b walks through creating and installing the App.
Step-by-step App creation (name, webhook off, permissions, install), where to
find App ID and Installation ID, and the two gotchas we hit: convert the private
key to PKCS#8 for Cloudflare Web Crypto, and delete a PAT-created summary comment
once when switching to the App (updates keep the original author).
githubClient(installationId) mints an installation token per event, so one App
serves every org/account it is installed on. The channel reads installation.id
from each webhook payload and threads it into the workflow input; the channel and
workflows then authenticate as that installation for all outbound calls.

GITHUB_APP_INSTALLATION_ID becomes an optional fallback — validateEnv now requires
only GITHUB_APP_ID + GITHUB_APP_PRIVATE_KEY for App mode. Backward compatible: a
plain repo webhook (no installation in the payload) falls back to the env id.

DEPLOY.md §2c documents the App-webhook path (configure once, install per repo)
for reviewing many repos or other orgs without per-repo webhooks.
…le App

isOwnerAllowed(owner) checks the repo owner against ALLOWED_OWNERS (comma-
separated, case-insensitive); the channel ignores events for any other owner
before doing any work — covering auto-review and the /review, /remember and
/feedback commands. Unset = allow all, with a startup warning when App auth is
configured without it.

Closes the abuse vector where anyone installing a public App (with the App
webhook on) would have their PRs reviewed on the operator's OpenRouter credits
and their repos read/written. DEPLOY.md §2c, README and env examples updated.
@ephor ephor merged commit 75fb7a0 into LingoVerse:main Jul 2, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants