🚀 Release v0.29.2

[github-actions]

This PR promotes changes from canary to main for version v0.29.2.

🔍 Changes Include:

• Version bump to v0.29.2
• All changes from canary branch

✅ Pre-merge Checklist:

• All tests passing
• Documentation updated
• Docker images built and tested

🤖 This PR was automatically generated by GitHub Actions

Greptile Summary

v0.29.2 release promoting canary to main. Key changes include cross-org security hardening across cluster, deployment, backup, schedule, and WebSocket handlers, a logWebhookError helper to stop leaking Drizzle SQL in webhook error responses, a redesigned invitation email template with organization name personalization, and a ssh2 upgrade to 1.16.0.

• P1 — Double-trigger in sync-version.yml: Adding push: tags: v* alongside release: published causes both events to fire when a release is created with a new tag. The parallel runs both attempt git push to the MCP and CLI repos; the second always fails with a non-fast-forward error, leaving every automated release with a failed workflow run.

Confidence Score: 4/5

Safe to merge for product code; the sync-version workflow will report a failure on every automated release until the double-trigger is fixed.

One P1 finding (workflow double-trigger causing push failures) caps the score at 4. All product-code changes are security improvements or bug fixes with no new regressions identified.

.github/workflows/sync-version.yml — double-trigger risk from simultaneous release and push:tags events.

_{Reviews (6): Last reviewed commit: "chore: add push trigger for version sync..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[greptile-apps]

pingInterval not cleared on early org-check return

The pingInterval created on line 79 is only cleaned up inside the ws.on("close", ...) handlers registered later (lines 141 and 172), but neither handler is ever registered when the organization check fails and the function returns early. The interval will keep firing every 45 seconds for the lifetime of the process. Because ws.readyState won't equal OPEN after ws.close(), no pings are actually sent, but the interval handle accumulates across all rejected connections.

Suggested change

	if (server.organizationId !== session.activeOrganizationId) {
	ws.close();
	return;
	}
	if (server.organizationId !== session.activeOrganizationId) {
	clearInterval(pingInterval);
	ws.close();
	return;
	}

[greptile-apps]

scheduleType change bypasses owner/admin role check in non-cloud mode

When an existing schedule has applicationId set, the serviceId branch is taken and only checkServicePermissionAndAccess runs. In non-cloud mode there is no guard against changing scheduleType, so a non-admin user who holds schedule:update permission on an application can send scheduleType: "server" and an arbitrary serverId in the update payload. updateSchedule(input) persists that change; the schedule then executes against a server (potentially from another org) without the owner/admin role check that the else branch enforces.

The IS_CLOUD type-change guard should also apply in self-hosted mode, or the server org/role checks should be repeated whenever input.scheduleType shifts to "server" or "dokploy-server".

[greptile-apps]

Email failure orphans the invitation record

sendInvitationEmail is called after the invitation has already been committed to the database. If the SMTP call fails (server unreachable, wrong credentials, etc.), the error propagates uncaught and TRPC returns a 500 to the client — but the invitation row is already persisted and the audit() on line 346 is skipped. On retry, the caller hits the "invitation already sent" conflict guard and gets a confusing error, since the invitation is valid in the DB but they never got a confirmation.

Contrast this with the equivalent path in user.ts, where the email send is wrapped in try/catch so a transient mailer failure doesn't fail the whole operation. The email send here should be wrapped similarly:

try {
    await sendInvitationEmail({ email, inviteLink, organizationName: org?.name || "organization" });
} catch (error) {
    console.error("Failed to send invitation email:", error);
}

[greptile-apps]

input.serverId not validated in update — cross-org server hijack

The org-membership check on lines 151–164 validates existingSchedule.serverId (the server currently stored), but updateSchedule(input) on line 177 persists the entire input payload — including any new serverId the caller provides. updateScheduleSchema extends createScheduleSchema which includes serverId, and updateSchedule does a plain .set(rest) on all input fields, so a user with update permission on a server-type schedule can silently redirect it to any server in any org simply by supplying a foreign serverId in the request body. Add the same org check against input.serverId before calling updateSchedule:

if (input.serverId && input.serverId !== existingSchedule.serverId) {
    const newServer = await findServerById(input.serverId);
    if (newServer.organizationId !== ctx.session.activeOrganizationId) {
        throw new TRPCError({
            code: "UNAUTHORIZED",
            message: "You don't have access to this server.",
        });
    }
}

[greptile-apps]

Double-trigger when release is published with a new tag

When a GitHub Release is created and a new tag is created in the same action (e.g., via the GitHub API or the Release UI with "Create new tag"), GitHub fires both release: published and push: tags: v* in parallel. Both workflow runs will clone the external repos, commit, and attempt to push. The first run's push succeeds; the second run fails with a non-fast-forward error because the remote has diverged. This causes a visible workflow failure on every automated release.

A common fix is to use a concurrency group with cancel-in-progress: true, or to guard with an if condition that distinguishes the two event types:

jobs:
  sync-version:
    concurrency:
      group: sync-version-${{ github.ref }}
      cancel-in-progress: true