Apache Release Notes

We are proud to announce the release of Apache Kafka® 4.3. This release contains many new features and improvements. This blog post will highlight some of the more prominent ones. For a full list of changes, be sure to check the release notes.

With 25 KIPs and over 600 commits since 4.2.0, this release introduces many new features, improvements and bug fixes to all the components.

See the Upgrading to 4.3 section in the documentation for the list of notable changes and detailed upgrade steps.

Deprecation Notices

• KIP-1244 Drop support for streams-scala in Kafka 5.0 (deprecate in 4.3)
  Deprecates the streams-scala module. Marked for removal in Apache Kafka 5.0.

• KIP-1237: Deprecate group.coordinator.rebalance.protocols config
  Deprecates the group.coordinator.rebalance.protocols broker configuration. Marked for removal in Apache Kafka 5.0.

• KIP-1280: Update MirrorMaker to use KIP-877 to emit metrics
  Deprecates the existing MirrorMaker metrics. They are marked for removal in Apache Kafka 5.0. Users should transition to the new metric names.

Kafka Broker, Controller, Producer, Consumer and Admin Client

• KIP-1023: Follower fetch from tiered offset
  Adds a new broker configuration, follower.fetch.last.tiered.offset.enable (default: false). When enabled the last tiered offset is used as the start offset when bootstrapping a new follower.

• KIP-1066: Mechanism to cordon brokers and log directories
  Introduces a new configuration, cordoned.log.dirs to cordon log directories. New partitions cannot be placed on a cordoned log directory. This can be used when scaling or decommissioning brokers or log directories.

• KIP-1196: Introduce group.coordinator.append.max.buffer.size config
  Introduces the group.coordinator.append.max.buffer.size and share.coordinator.append.max.buffer.size configurations to set the maximum buffer size the coordinators can use. There are also metrics to track the buffer usage.

• KIP-1208: Add prefix to TopicBasedRemoteLogMetadataManagerConfig to enable setting admin configs
  Introduces a new prefix remote.log.metadata.admin. for setting configurations for the admin client used by the tiered storage’s RemoteLogMetadataManager.

• KIP-1211: Align the behavior of num.partitions and default.replication.factor for topic creation
  Fixes inconsistencies how num.partitions and default.replication.factor were applied when creating topics.

• KIP-1219: Configurations for KRaft Fetch and FetchSnapshot Byte Size
  Adds new broker configurations, controller.quorum.fetch.snapshot.max.bytes and controller.quorum.fetch.max.bytes, to control the maximum amount of data Fetch and FetchSnapshot requests can retrieve.

• KIP-1235: Correct the default min.insync.replicas to 2 for the __remote_log_metadata topic
  Adds a new broker configuration, remote.log.metadata.topic.min.isr, to set the minimum in-sync replicas for the internal topic used by tiered storage.

• KIP-1240: Additional group configurations for share groups
  Adds a number of new broker and group configurations to control the behavior of share groups.

• KIP-1251: Assignment epochs for consumer groups
  Improves the member epoch validation logic to avoid unnecessary fencing of group members.

• KIP-1257: Partition Size Percentage Metrics for Storage Monitoring
  Introduces new metrics to track how much of the maximum retention each topic-partition currently uses.

• KIP-1258: Add Support for OAuth Client Assertion to client_credentials Grant Type
  Adds support for client assertion authentication to client_credentials grant type with OAuth to enhance security and compatibility with OAuth providers.

• KIP-1263: Group Coordinator Assignment Batching and Offload
  Improves the group coordinator assignment logic to avoid recomputing assignments when unnecessary.

• KIP-1274: Deprecate and remove support for Classic rebalance protocol in KafkaConsumer (Phase 1)
  Logs a message when starting a consumer with the classic rebalance protocol recommending to use the new consumer rebalance protocol instead as the classic protocol will be deprecated in a future release.

Kafka Streams

• KIP-1035: StateStore managed changelog offsets
  Adds methods to the StateStore API to manage changelog offsets. This is an internal runtime change, and only relevant for custom StateStore implementations.

• KIP-1247: Make Bytes utils class part of the public API
  Exposes the Bytes class as part of the public API so it appears in the javadoc.

• KIP-1250: Add metric to track size of in-memory state stores
  Adds new metrics tracking the number of keys in the in-memory state stores.

• KIP-1259: Add configuration to wipe Kafka Streams local state on startup
  Adds a new configuration, state.cleanup.dir.max.age.ms, to automatically delete state directories that have not been modified for that duration on startup.

• KIP-1270: Extend ProcessingExceptionHandler for GlobalThread
  Adds a new configuration, processing.exception.handler.global.enabled, to enable ProcessingExceptionHandler to handle GlobalKTable exceptions.

• KIP-1271: Allow to Store Headers in State Stores
  Extends the Processor API to support record headers in state stores.

• KIP-1285: DSL Opt-in Support for Headers-Aware State Stores
  Exposes Headers-Aware State Stores (KIP-1271) to the DSL API.

Kafka Connect

• KIP-1239: Batch offset translation in RemoteClusterUtils
  Adds a new method RemoteClusterUtils.translateOffsets() to translate the committed offsets of several consumer groups at the same time.

• KIP-1273: Improve Connect configurable components discoverability
  Introduces a new interface, ConnectPlugin, that all Kafka Connect plugins implement to ensure common methods across all plugin types.

• KIP-1280: Update MirrorMaker to use KIP-877 to emit metrics
  Adds a new configuration, metric.names.formats, for MirrorSourceConnector and MirrorCheckpointConnector to opt-in to the new metric names.

Summary

Ready to get started with Apache Kafka 4.3.0? Check out all the details in the upgrade notes and the release notes, and download Apache Kafka 4.3.0.

This was a community effort, so thank you to everyone who contributed to this release, including all our users and our 147 contributors (and 3 AIs):
高春晖, 조형준, Abhijeet Kumar, Abhinav Dixit, Alieh Saeedi, Alyssa Huang, Andrew Schofield, Aneesh Garg, Angelo R., Anton Vasanth, ANUSHREE BONDIA, Apoorv Mittal, Arpit Goyal, Artem Livshits, averemee-si, Bill Bejeck, Bolin Lin, Calvin Liu, Chang-Chi Hsu, Chang-Yu Huang, Chia-Ping Tsai, Chia-Yi Chiu, ChickenchickenLove, Chih-Yuan Chien, Chirag Wadhwa, Chris Egerton, Christo Lolov, Claude, Claude Sonnet 4.6, Copilot, cui, Dale Lane, David Arthur, David Jacot, Deepak Goyal, Dejan Stojadinović, dengziming, Ding, Dmitry Werner, Dongnuo Lyu, Donny Nadolny, Edoardo Comar, Eduwer Camacaro, Emanuele Rabino, Emmanuel Oppong, Eric Chang, Erik Anderson, Evan Zhou, Federico Valeri, Fiore Mario Vitale, gabriellefu, Gaurav Narula, Gianmarco, Giuseppe Lillo, gomudayya, Gyeongwon, Do, Harish Vishwanath, Hector Geraldino, high.lee, Himanshu Verma, Hong-Yi Chen, Hy (하이), hy-rice, Ibuki Kaji, Ilyas Toumlilt, Ismael Juma, Izzy Harker, J.V.S Aarathi, Jacob Montemayor, JeevanYewale, Jhen-Yung Hsu, Jian, Jiayao Sun, jimmy, Jinhe Zhang, Joanna-D, Jonah Hooper, José Armando García Sancio, Josep Prat, Jun Rao, Justine Olshan, k-apol, Kamal Chandraprakash, Ken Huang, Kevin Wu, khilesh Chaganti, Kirk True, Kuan-Po Tseng, Lan Ding, Levani Kokhreidze, Lianet Magrans, Lucas Brutschy, Lucy Liu, Luke Chen, Ma Jialong, Mahsa Seifikar, manan.gupta, Manikumar Reddy, mannoopj, Maros Orsak, Matthias J. Sax, Mickael Maison, Ming-Yen Chung, Moshe Blumberg, Murali Basani, Nandini Singhal, Nick Guo, Nick Telford, Nikita Shupletsov, Nilesh Kumar, Lan Ding, Paolo Patierno, Park Jiwon, Parker Chang, Philippus Baalman, PoAn Yang, Prabhash Kumar, Raghu Baddam, Rajarshi Misra, Rion Williams, Rion Williams,, Ritika Reddy, Robin Marechal, runom, S.Y. Wang, Saket Ranjan, Sanskar Jhajharia, Santhan3159, Sean Quah, Shashank, Shivsundar R, Siddhartha Devineni, sstremler, Steven Schlansker, Stig Døssing, Sushant Mahajan, TaiJuWu, TengYao Chi, Tirth, tison, Uladzislau Blok, Viktor Somogyi-Vass, Vincent Jiang, Vincent Potuček, Xuan-Zhang Gong, Zheguang Zhao, Zhiyan Tang, zoo-code

Summary

• Reframe the Slack agent's SYSTEM_PROMPT opener — it described the bot as a task-management assistant, but it can also spawn workspaces and run coding agents.
• Add that capability to the "You can" list and add one guideline so the bot defaults to action: for code-change requests, prefer spawning a workspace + agent over just filing a task.

Why / Context

For "can someone fix X" style messages the bot tended to file a task or ask questions rather than kick off the work, partly because the prompt only framed it around task tracking. This nudges it toward action while keeping it a general Slack assistant.

Testing

• bunx biome check on the changed file — clean
• No automated tests added (prompt-text-only change)

Notes

• Only the static SYSTEM_PROMPT string changed; the dynamic context interpolation (org, channel, members, statuses, hosts) is untouched.
• The prompt is shared across the v1 and v2 MCP feature-flag paths (FEATURE_FLAGS.SLACK_MCP_V2). Workspace/agent spawning is a v2 capability; on v1 the bot adapts to the tools it's given.

Summary by CodeRabbit

Improvements

• Slack assistant prompt updated to focus on Superset-related tasks and tool usage.
• Guidance restructured to emphasize using Superset tools, workspace spawning, and launching coding agents.
• Assistant more proactive: when intent is clear (especially for code changes), it favors spawning a workspace/agent to take action.
• Retains task creation, formatting, error handling, sourcing, and context-gathering behaviors.

Greptile Summary

This PR rewrites the static SYSTEM_PROMPT in the Slack agent to make the bot proactively spawn workspaces and launch coding agents for code-change requests, rather than filing a task or asking clarifying questions.

• Bias toward action section added: the model is instructed to spawn a workspace + agent whenever intent is reasonably clear, reserving tasks for explicit "track for later" requests.
• Spawning workspaces and agents section added: step-by-step guidance to call superset_projects_list, check superset_workspaces_list for duplicates, derive a kebab-case branch slug, match the user's online host, and spawn via superset_workspaces_create/superset_agents_run.

Confidence Score: 3/5

The change is prompt-only, but the new spawning guidance names v2-specific tools that don't exist on the v1 code path, and the bias-toward-action instruction amplifies the impact of that mismatch on every code-change request routed through v1.

The new sections hard-reference four tool names absent on the v1 MCP path; with the bias-toward-action instruction now in place, the model will actively try to spawn for any code-change request and on v1 will either error out or appear to comply without actually doing anything.

apps/api/src/app/api/integrations/slack/events/utils/run-agent/run-agent.ts — the v1/v2 tool-name mismatch in the new prompt sections warrants a second look before merging.

Spawning workspaces and agents

• Before spawning, call superset_projects_list and pick the project that best matches the request. Match on repository name, project slug, and topic keywords drawn from the user's message and the thread/channel context.
• If the request concerns the Slack app, Superset features, the tasks or automations UI, or anything about Superset itself, use the Superset project (slug: superset).
• If several projects could plausibly match, pick the strongest candidate, state in one short sentence which you picked and why, and proceed — don't stall on the choice.
• Also call superset_workspaces_list and check for an existing active workspace on a relevant branch. superset_workspaces_create always creates a new workspace, so when a relevant one already exists, mention it to the user instead of silently duplicating it.
• Derive the branch name from the request as a short kebab-case slug (e.g. fix-slack-retry, add-csv-export).
• For the host, use the requesting user's own machine when it appears online in the Hosts list in your context (match the host name against the current user); otherwise fall back to the sandbox host.
• Spawn the agent as part of workspace creation when possible — superset_workspaces_create accepts an agents array — or call superset_agents_run against the workspace afterward. Use the claude agent preset unless the user asks for another. Give the agent a clear, self-contained prompt describing the change to make.

Hardcoded superset slug is a silent failure risk

The prompt hard-wires the string superset as the project slug for all Superset-related requests. If that project is ever renamed or its slug changes in the database, the bot will silently pass the wrong slug to superset_workspaces_create and the spawn will fail (or land in the wrong repo). A softer phrasing — e.g. "use the project whose slug or name best matches 'superset'" — would let the model recover by calling superset_projects_list and selecting the closest match at runtime.

Additional notes:

• Host-to-user name matching may always fall through to sandbox because the instruction assumes a host's name field correlates with the current user's display name or email, which may not hold true.
• Consider surfacing ownership metadata to make the heuristic more reliable.

Overall, this update makes the Slack agent more proactive in spawning workspaces and launching coding agents for code-change requests, improving efficiency and responsiveness.

Superset is now usable from a lot more places than the desktop app: a fleshed-out CLI and TypeScript SDK, a Slack agent that spins up workspaces on its own, and a mobile app heading into internal review.

Automations

Automations are cron jobs for agent sessions. Pick a project, write a prompt, set a schedule — and Superset dispatches an agent run against a fresh workspace every time it fires. The output is a live workspace you can open, review, and continue interactively.

Typical uses:

• Nightly standups — summarize PRs, issues, and activity from the last 24 hours
• Release notes — draft from merged commits each week
• Security & dependency sweeps — scan for vulnerable packages or deprecated APIs every morning
• Long-running refactors — "bump TypeScript to 5.7 in the next un-migrated package" on a daily cadence

This batch brings automations into their own as a first-class workflow:

• Prompt version history — every edit to an automation's prompt is snapshotted. Browse previous versions and restore any of them, so an accidental change is no longer a one-way door.
• Redesigned automations tab — new layout that makes a queue of runs easier to scan at a glance.
• Mine vs. Team filter — automations now belong to a team. Filter the runs view between Mine and Team to see only what you ran vs. everything your team kicked off.

Drive them from the CLI

Everything you can do in the UI is now scriptable. New in this batch: prompt get / prompt set and the --name filter on list.

# create a recurring run from a prompt file
superset automations create \
--name "Nightly audit" \
--rrule "FREQ=DAILY;BYHOUR=3;BYMINUTE=0" \
--project <projectId> \
--agent claude \
--prompt-file prompt.md

# manage the queue
superset automations list --name "Nightly"
superset automations pause <id>
superset automations resume <id>

# iterate on the prompt (backed by the new version history)
superset automations prompt get <id> > prompt.md
$EDITOR prompt.md
superset automations prompt set <id> --file prompt.md

# fire one off-schedule (also works from the SDK / Slack bot / MCP)
superset automations run <id>

superset automations run is also exposed via the TypeScript SDK and MCP, so you can dispatch runs from a CI job, an internal admin panel, or a Slack slash command. See the Automations docs for the full surface.

Superset CLI

The superset CLI grew real project and workspace commands and a cross-device login flow.

New commands:

• superset projects create — scaffold a new Superset project from your shell.
• superset projects setup — link an existing local repo to a Superset project.
• superset workspaces open — open a workspace directly from the terminal.
• superset auth login — now uses OAuth device code + PKCE, so it works on headless servers and across devices.

Setting it up:

# install
curl -fsSL https://superset.sh/cli/install.sh | sh
# or: brew install superset-sh/tap/superset
# or: it's already bundled with the desktop app at ~/.superset/bin/superset

# sign in (opens a browser, or prints a code for a second device)
superset auth login

# scaffold a project and open a workspace
superset projects create
superset workspaces open

The accompanying TypeScript SDK (@superset_sh/sdk) mirrors the CLI 1:1 — same procedures, same shapes — so anything you can do from your shell, you can do from a script, a CI job, or an internal tool.

Linux superset start and superset update are now fixed.

Slack bot

@superset in Slack is now an actual agent, not a task-filer. Mention it in a channel or DM it from anywhere, and it can:

• Create, update, search, and triage tasks from the conversation it's standing in — pulling assignees, statuses, and priorities from your team's Linear/Superset setup.
• Spin up a cloud workspace and launch a coding agent to actually do the work. For code-change requests (e.g. "@superset bump our Sentry SDK to v9 across all apps"), it now defaults to spawning a workspace and agent rather than just filing a ticket.
• Read the thread or channel history on its own to gather context — no need to copy-paste the prior messages.
• Search the web with citations when a request needs up-to-date info.
• Unfurl Superset task and workspace links with rich previews when they're shared in a channel.

Setting it up:

In the dashboard, go to Integrations → Slack.
Click Connect to install the Superset Slack app into your workspace (OAuth).
Mention @superset in any channel, or open a DM with the bot, and describe what you want done.

If Slack was already connected before this release, no action needed — proactive workspace creation is on by default.

Mobile: internal review

The mobile app is in internal review. Core flows — workspaces list, task triage, agent chat, and the live terminal viewer — are wired up against the same APIs as web and desktop. We're dogfooding on-device now ahead of a wider beta.

Also in this batch

• Teams as a first-class primitive — assign members, workspaces, and automations to a team. Powers the Mine/Team automations split above.
• Terminal sessions survive app updates — the PTY daemon hands off file descriptors on upgrade, so running shells stay alive when Superset auto-updates.
• Web terminal presets — run your common commands with a single click in the web terminal, same as desktop.

Minor updates

V2 changes tab gained inline stage/unstage/discard controls and diff comments gained a copy action. Workspaces can be started with a preset for repeatable agent runs. The relay server now drains tunnel connections cleanly on shutdown ahead of the multi-region rollout. Theme search in the command palette. macOS notifications now include workspace and project context. MCP OAuth access token TTL bumped to 7 days.

Add a web terminal preset bar backed by host agent configs, including the shared preset SVG icons used by desktop.

Let web terminal creation pass an initial command so preset clicks launch the selected terminal agent.

Write NEXT_PUBLIC_RELAY_URL from the workspace setup script alongside RELAY_URL so browser host-service calls use the allocated relay port.

Summary by cubic:

Adds a web terminal presets bar powered by host agent configs, letting users launch a preconfigured terminal in one click. Also enables browser host-service calls via NEXT_PUBLIC_RELAY_URL so the relay port is used correctly.

New Features:

• Presets bar with shared SVG icons, loading state, and disabled/running states.
• Terminal creation accepts an initial command; clicking a preset builds the agent launch command and opens a terminal.
• Host client: settings.agentConfigs.list to fetch presets and a helper to build the launch command; supports GET requests without input.
• Adds svg.d.ts to allow importing preset SVGs.

Migration:

• Re-run the workspace setup to write NEXT_PUBLIC_RELAY_URL to the environment and restart the web app.

Summary by CodeRabbit:

New Features:

• Added a terminal presets bar above the terminal area, allowing users to quickly launch predefined terminal configurations.
• Terminal presets can now be executed with a single click, automatically creating new terminal sessions.
• Improved terminal selection logic to better manage active terminal sessions.

Bug Fixes:

• Enhanced error handling and messaging during terminal operations.

Greptile Summary:

This PR adds a web terminal presets bar that fetches host agent configs and lets users launch a preconfigured terminal session in one click. It also fixes the relay URL for browser-side host calls by writing NEXT_PUBLIC_RELAY_URL during workspace setup, and replaces the useEffect-driven terminal selection with a cleaner derived activeTerminalId.

Presets bar: WebTerminalPresetsBar renders preset buttons with SVG icons, per-button loading spinners, and a loading skeleton while configs are fetched; presets and terminals are loaded concurrently via Promise.allSettled.

Shell command builder: buildHostAgentLaunchCommand single-quotes argv and overlays env vars, but does not incorporate promptArgs/promptTransport from the config — clarify whether those fields are intentionally out of scope for the initial launch.

Settings button: The "Manage presets" gear icon button in the bar renders as interactive but has no onClick handler attached.

Confidence Score: 4/5

Safe to merge; the shell-quoting helpers and state management changes are correct, with two areas that need clarification or a quick follow-up.

The core plumbing — relay URL, parallel preset/terminal loading, derived active terminal, and per-preset launch — is sound. Two items warrant attention: the Settings gear button is visually interactive but wired to nothing, and buildHostAgentLaunchCommand silently ignores promptArgs/promptTransport, which may be intentional but could also mean presets launch the agent binary without the expected initial prompt.

Additional notes:

• The Settings button is a no-op and should either be wired up or disabled/removed to avoid confusing UX.
• Env variable keys are not shell-safe in envOverlayPrefix function; validation is recommended to prevent silent breakage or injection.
• promptArgs and promptTransport are never used in the launch command; if the host agent needs an initial prompt injected, this needs to be wired into buildHostAgentLaunchCommand.

Overall, this update introduces a new web terminal presets feature with improved usability and environment configuration, while highlighting some areas for follow-up improvements.

Summary

• superset start — ship @mastra/core (peer dependency of the unbundled @mastra/duckdb) into the CLI bundle; fresh installs were crashing at host-service boot with ERR_MODULE_NOT_FOUND.
• superset update — stage the download on the install filesystem so the final rename doesn't fail with EXDEV when /tmp is a separate mount (the common Linux case).
• Harden the Linux build smoke tests to actually exercise @mastra/duckdb, so this class of bug can't ship undetected again.

Why / Context

Two regressions made the standalone CLI unusable on Linux after the recent CLI port.

superset start crash.

@mastra/duckdb ships unbundled (its native bindings can't be inlined into host-service.js) and declares @mastra/core as a peerDependency. build-dist.ts's copyPackageWithDeps only walked dependencies, so @mastra/core and its transitive closure never landed in lib/node_modules. Every fresh install crashed on the first superset start:

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@mastra/core' imported from .../lib/node_modules/@mastra/duckdb/dist/index.js

superset update crash.

The updater staged the new release via mkdtempSync(tmpdir()) then renameSync()'d it onto the install root. On Linux /tmp is typically a separate mount (tmpfs), so the cross-filesystem rename failed:

Error: EXDEV: cross-device link not permitted, rename '/tmp/superset-update-XXX' -> '/home/user/superset'

How It Works

• build-dist.ts — copyPackageWithDeps now also walks non-optional peerDependencies, recursively. A package shipped unbundled must have its peers resolvable from disk at runtime (a bundled consumer's inlined copy is invisible to it). Peers the installer didn't materialize are skipped best-effort; dependencies stay fatal-if-missing.
• update/command.ts — the staging temp dir is created as a sibling of the install root (mkdtempSync(${installRoot}.update-`)) instead of in tmpdir(), so the final renameSync is always an intra-filesystem move.
• Smoke tests (build-dist-linux-docker.sh + build-cli.yml) — after building, they now import("@mastra/duckdb") as ESM from a script placed inside lib/, mirroring how host-service.js resolves it. The previous smoke test only require()'d four native packages and never touched the host-service runtime imports — which is exactly why bug 1 shipped.

Manual QA Checklist

☑ Docker linux-x64 build passes the hardened smoke test (@mastra/duckdb OK)
☑ Docker linux-arm64 build passes the hardened smoke test
☑ superset update EXDEV — reproduced the old failure with the published 0.2.17 binary under a separate-device /tmp, confirmed the patched binary succeeds
☑ Fixed build's host service boots end-to-end on a real Linux host (Fly machine) — listening + health.check OK
☑ A real mastra chat conversation works against the fixed build's host service

Testing

• bun run typecheck
• bun run lint
• Docker builds for both Linux targets via packages/cli/scripts/build-dist-linux-docker.sh (mirrors CI)

Known Limitations

• Separate, pre-existing issue (not addressed here): the host service holds a static auth token, so the relay tunnel can't re-authenticate once it expires. A ticket is being drafted for that.
• The @mastra/core fix overlaps with commit 056771967 on feat-relay-graceful-drain (a simpler NATIVE_PACKAGES one-liner); whichever lands second should drop the duplicate. The peer-dependency walk here is the more general fix.

Risks / Rollout

• Risk: low — build-script + CLI-command changes only; no schema or API surface. The peer-dep walk only adds packages to the bundle (the tarball grows because @mastra/core's tree now ships, as required).
• Rollback: revert the two commits; the next CLI release returns to the prior build-dist.ts / update behavior.

Summary by cubic

Fixes Linux failures in superset start and superset update. Bundles the missing @mastra/core peer for @mastra/duckdb and stages updates on the install filesystem to avoid EXDEV errors.

Bug Fixes

• Bundle non-optional peerDependencies for unbundled packages; ensures @mastra/core is present for @mastra/duckdb (prevents ERR_MODULE_NOT_FOUND on fresh installs).
• Stage downloads as a sibling of the install root and rename in-place; avoids cross-device rename (EXDEV) when /tmp is a separate mount.

Tests

• Hardened Linux smoke test to import @mastra/duckdb as ESM from inside lib/, mirroring host-service resolution.

Release Notes

Bug Fixes

• Improved update process stability by optimizing temporary directory placement to prevent cross-filesystem operation failures.

Chores

• Upgraded build system to gracefully handle optional peer dependencies.
• Enhanced smoke tests to verify DuckDB compatibility across different module resolution scenarios in CI and Docker builds.

Discovered during a multi-region rolling-deploy game-day on superset-relay-staging: every relay-machine restart left host tunnels disconnected for ~60s before they reconnected. That outage compounds across regions during multi-region deploys, so it's a blocker for rolling multi-region to prod cleanly.

Root cause

1. Fly sends SIGTERM to the relay process during a rolling deploy.
2. Relay had no SIGTERM handler — the process just exits, leaving every open WS as a TCP-RST'd socket from the host's perspective.
3. Host-service's exponential reconnect backoff (RECONNECT_BASE_MS=1s, RECONNECT_MAX_MS=30s) climbs into the 30s/attempt tail after 6 failed attempts while the relay is down (30-40s).
4. By the time the relay comes back, the host is mid-30s-wait. Worst case is ~60s before the next attempt fires and the WS re-establishes.

Game-day timings

• 04:02:41Z — SJC machine restart (sandbox WS killed)
• 04:02:42Z — SJC listening again
• 04:03:45Z — sandbox re-registered (63s gap from restart)

Fix (two-sided)

Relay (apps/relay/src/tunnel.ts + apps/relay/src/index.ts)

• New tunnelManager.drain() that walks every open WS and closes it with code 1001 ("Going Away"), waits 250ms for close frames to flush, then exits.
• Wired to SIGTERM in index.ts so Fly's pre-stop signal triggers the clean drain.

Host (packages/host-service/src/tunnel/tunnel-client.ts)

• socket.onclose now recognizes code 1001 specifically and resets reconnectAttempts = 0 before scheduling the next attempt. The next reconnect fires at the 0.5-1s base delay instead of the saturated 30s tail.

Together: deploy outages should drop from ~60s to ~2-5s per affected host.

Test plan

• Deploy this branch to superset-relay-staging via ./apps/relay/scripts/deploy-staging.sh.
• Re-run the rolling-deploy game-day: trigger a redeploy, watch sandbox + satyas-mbp tunnels in staging logs, confirm re-registration happens within ~5s of each machine coming back (instead of ~60s).
• Confirm no zombie directory entries — disposeTunnel cleans pingTimer/pendingRequests on close, and the existing unregister path on the next onclose of the host-side socket fires correctly.

Out of scope (separate concerns to track)

• The shorter-term mitigation "lower RECONNECT_MAX_MS" was considered but rejected — under genuine sustained outages we still want backoff to prevent storms. The 1001-reset path is the right shape: fast retry only when the relay clearly told us "I'm going away".
• Cloud-DB lag (is_online staying stale after re-register) — tracked separately; this PR doesn't touch the scheduleOnlineWrite path.
• Synthetic check on staging — nice-to-have but not blocking.

Summary by cubic

Gracefully drains relay tunnels on SIGINT/SIGTERM: stop new connections, send an in-band “drain” message, close with WS code 4001 so hosts reconnect immediately, and await directory cleanup before exit. Cuts deploy-time outages to ~1–5s, clears stale directory entries, and adds Fly lifecycle settings plus region-aware smoke tests for safer multi‑region deploys.

New Features

• Relay (apps/relay): on SIGINT/SIGTERM call server.close(), broadcast {type:"drain"}, close with code 4001, reject new registers while draining, await batched directory cleanup, then exit. Set kill_signal = "SIGINT" and kill_timeout = "10s" in fly.toml and fly.staging.toml.
• Host (packages/host-service): on {type:"drain"} or close code 4001, reset reconnectAttempts and reconnect immediately; cap RECONNECT_MAX_MS at 5s. Protocol adds drain message (packages/shared).
• Deploy/ops: add apps/relay/scripts/deploy-staging.sh; add region-aware smoke-test.sh and run it from both deploy scripts to verify /health per region.

Bug Fixes

• Relay directory: batch-clear self-owned entries via a single Redis EVAL on startup and during drain; await cleanup before exit to prevent stale routing and incorrect is_online.

Summary by CodeRabbit

New Features

• Relay now gracefully drains active connections on shutdown to reduce abrupt disconnects.
• Relay startup clears stale directory entries from prior processes to avoid stale state.
• Tunnel clients detect relay-initiated shutdowns and reconnect immediately with faster retry behavior.

Chores

• Added deployment script and runtime lifecycle settings to enable rolling deploys with graceful shutdown.

Additional notes from greptile-apps Bot

This PR adds a graceful tunnel-drain path to the relay so that rolling deploys no longer leave host-services in exponential-backoff limbo (~60 s) after a SIGTERM. The relay closes every open WebSocket with code 1001 before exiting, and the host-service now recognises code 1001 as a clean drain signal and resets its reconnect counter so it retries within ~1 s.

Confidence Score: 3/5

Known issue: The close-code collision with the existing ping-timeout path means the host-service cannot distinguish the two scenarios and may trigger reconnect storms under load. The relay's existing ping-timeout handler already closes host sockets with code 1001. The new client-side logic resets backoff for any code-1001 close, so a wave of ping timeouts during relay overload would produce the same thundering-herd that the exponential backoff was designed to suppress. apps/relay/src/tunnel.ts and packages/host-service/src/tunnel/tunnel-client.ts need a consistent, distinct close code for the deploy-drain signal vs. the ping-timeout path.

Code changes include wiring SIGTERM to tunnelManager.drain(), which closes all tunnels with WS code 1001 and waits 250 ms for frames to flush, then exits. The host-service resets reconnectAttempts=0 when event.code === 1001, bypassing saturated backoff for what the client treats as a clean relay restart.

The deploy-drain path reduces deploy outages from ~60s to ~2-5s per host, improving multi-region rolling deploy stability.

Adds richer native macOS notification content for v2 workspace agent lifecycle events. Instead of generic Agent Complete / Your agent has finished copy, notifications now include the agent label, workspace name, pane label, and tab label when available.

Why

The v2 notification pipeline already receives agent identity and can resolve workspace/pane layout context, but the native notification copy only used generic text. That made it hard to tell which agent, pane, or workspace finished when multiple agents were running.

Changes

• Threads workspace display names into the v2 host notification subscriber.
• Adds a focused notification content formatter for agent, workspace, pane, tab, terminal title, and fallback labels.
• Uses the formatter when showing native notifications from v2 lifecycle events.
• Adds unit coverage for completion, permission request, and fallback notification content.

Validation

• bun test apps/desktop/src/renderer/routes/_authenticated/components/V2NotificationController/lib/notificationContent.test.ts apps/desktop/src/renderer/routes/_authenticated/components/V2NotificationController/lib/resolveV2NotificationTarget.test.ts apps/desktop/src/renderer/routes/_authenticated/components/V2NotificationController/lib/statusTransitions.test.ts
• bun run lint
• bun run --cwd apps/desktop typecheck

Summary by cubic

Switches v2 macOS notifications to agent‑first titles and a simpler body. Titles are “{Agent} - Complete/Needs Attention”; the body shows only the workspace name.

• New Features
  • Title format: “{Agent} - Complete” or “Needs Attention” for permission requests.
  • Body: “{WorkspaceName}” (trimmed; falls back to name → branch → “Workspace”).
  • Agent labels resolve via @superset/shared/agent-catalog or humanized ids; threaded workspaceName through and added unit tests.

Summary by CodeRabbit

• New Features
  • Notifications now display a cleaned workspace name (trimmed, falling back to branch or generic "Workspace") and use concise native notification titles combining agent label + action.
• Bug Fixes
  • Removed noisy/ambiguous label content and simplified title selection for clearer notifications.
• Tests
  • Added tests for notification title/body generation, permission-request wording, and fallback labeling.

This PR enriches native macOS notifications for v2 agent lifecycle events by adding contextual labels (agent, workspace, pane, tab) instead of the previous generic "Agent Complete / Your agent has finished" copy. The notification pipeline already carried agent identity; this change threads workspace display names and pane layout data through to a new getV2NativeNotificationContent formatter and wires it into the notification render path.

Important files changed include:

• notificationContent.ts — new formatter that resolves agent label (with BUILTIN_AGENT_LABELS lookup and humanizeIdentifier fallback), workspace name (name → branch → id), pane label (title override → runtime terminal title → kind label → short terminal ID), and tab label (title override → "Tab N" index), then composes them into title/body.
• lifecycleEvents.ts — showNativeNotification now calls terminalRuntimeRegistry.getTitle with the pane ID as the instance discriminator (matching how TerminalPane registers entries) before falling back to the primary entry, and passes both workspaceName and paneLayout to the formatter.
• V2NotificationController.tsx — the workspace live-query now selects name and branch (both notNull columns) and computes workspaceName before grouping by host URL.

Confidence Score: 4/5

Safe to merge; changes are isolated to the notification formatting path and do not touch agent execution, data persistence, or auth flows. The notification formatter is well-structured with graceful fallbacks at every label level and the unit tests cover the main scenarios. Two minor points worth a quick look: the PANE_KIND_LABELS index type hides an implicit runtime undefined from TypeScript, and shortId can produce 'Terminal terminal' for the rare case where the terminal ID is exactly the stripped prefix. Neither affects correctness for real workspaces.