chore: update @flue/* + tooling to beta.9, migrate to new runtime API#2
Conversation
There was a problem hiding this comment.
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.
6700622 to
5a7146e
Compare
…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.
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).
…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.
Summary
@flue/runtimeand@flue/cli1.0.0-beta.2/beta.1→beta.9(plusvalibot,@types/node,oxfmt,oxlint) and migrates the code to the breaking beta.9 API.export default defineWorkflow({ agent, input, run })with anActionContext-typed handler instead ofexport async function run+FlueContext<Payload>; harness comes from context instead ofawait init(agent). The passthroughrouteexport is kept — it still gatesPOST /workflows/:name.inputschema); inferred types are re-exported for the channel.defineTool:parameters/execute→input/run({ input }); tests updated to match.log.tsuses the now-exportedFlueLoggertype directly.post-review.ts:interface PostResult→type(needed for JSON-assignability under the new API).@flue/githubstays atbeta.1— it's the only published version and has no dependency on@flue/runtime.oxfmtacross the repo (formatting-only diffs in README,channels/github.ts,lib/retry.ts,workflows/admin.ts).Test plan
bun run typecheck— cleanbun run lint(oxlint) — cleanbun run test— 76/76 pass (on Node 22.23.1; repo'senginesrequires>=22.19.0)POST /workflows/:nametreats the raw JSON body asinput(no{ input }wrapping), matching whatsrc/channels/github.tssends.