Skip to content

Tale v0.5.45

Choose a tag to compare

View all tags
@larryro larryro released this 21 Sep 09:01
v0.5.45
bb3f447
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

0.5.45 carries four merged pull requests and one direct commit — every change since 0.5.44. Three numbers have gone by since the last curated notes, 0.5.41. v0.5.42 was tagged on 2026-09-20 but its container test gate failed — the pull request it was cut on had just switched the gate from rebuilding every image on the runner to validating the pulled release images, and the sandbox spawner's local image aliases were not yet re-tagged from those pulls, which the next number added — so no multi-architecture manifest, no latest tag, no GitHub release and no executables were published under it, and the number is skipped. 0.5.43 and 0.5.44 were published with generated notes: 0.5.43's list names one pull request and 0.5.44's four, so the other nine changes in that window — pull requests #3436–#3440, which 0.5.43 was the first to ship, and four direct commits — are named in no release notes, and the window's move of the machine contract from 1.19.0 to 1.20.0 is recorded nowhere. This page says what that window changed where it matters to an operator and treats its known issues as unrecorded.

Three themes in 0.5.45. The identity provider's library moves to the Better Auth 1.7 line, which closes the audience advisory the 0.5.33 notes flagged (GHSA-p2fr-6hmx-4528), takes the schema and API renames that came with it, and keeps the platform's plain-SQL team provisioning working across a column the new line declares without a default. A project file an agent wrote — a desk's invoice reading, a generated report — now offers Delete on its project row, which had been hidden together with the connector-synced rows. And the component library's own site, ui.tale.dev, stops sending a German or French reader to a page that does not exist, and its front page is rebuilt in the marketing design language it documents. The contract stays at 1.20.0, no numbered migration ships, Better Auth's own migrator adds three tables and columns on seven at boot, no environment variable changes, and no image in the stop-gated tier changes, so a plain tale deploy is the whole upgrade — with one caveat for a deployment that provisioned a native OIDC client through the CLI, under Known issues.

Highlights

The identity provider moves to Better Auth 1.7.5 and closes the audience advisory (#3447)

The better-auth family — the core, @better-auth/oauth-provider behind Continue with Tale, @better-auth/api-key, @better-auth/passkey and their adapters — moves from 1.6.30 to 1.7.5. Before 1.7.0 a client could choose its access token's audience at the token endpoint without that choice being bound to the authorization grant (GHSA-p2fr-6hmx-4528, CVSS 6.4, medium; the change and the 0.5.33 notes also cite it as CVE-2026-67332). This deployment was never exploitable — the provider is configured with no external audience and the authorization-code grant only, the advisory's own workaround, in place since the provider shipped — but the fixed line is the remedy, and the 1.6.x line is not patched. The breaking changes of the 1.7 line are absorbed: the OIDC client's application type is application_type on the wire and applicationType in the store (was type); the public column is gone (a public client is now one whose token-endpoint auth method is none, which the CLI's policy refuses either way); the two-factor enable answer is a discriminated union whose secret-less arm both enrolment screens now refuse rather than rendering an empty QR code; and client creation runs inside the adapter's transaction. Better Auth 1.7 also probes the live schema when the instance is built and logs any mismatch; that probe is switched off, because the boot already reconciles the schema deliberately — it runs Better Auth's own migrator inside the app-wide advisory lock — and a rolling deploy would otherwise log a mismatch from the previous image for every column the new one is mid-way through adding.

One production break the real-Postgres gate caught and CI cannot see: 1.7 adds team.memberCount as NOT NULL with an application-level default only, and this codebase owns team membership in plain SQL — SCIM group provisioning and single-sign-on team mapping never call Better Auth's team API — so every one of those inserts would have failed on roll. The boot now gives the column a SQL default of 0 right after Better Auth's migrations, every boot, idempotently; the value is deliberately not maintained, because nothing reads it — the Teams surfaces count members live.

A project file an agent wrote can be deleted from the project (#3445)

The project Knowledge tab hid a row's Delete for every source other than a plain upload, which swept in the files an automation writes into a project. Such a row has no external sync behind it, so nothing restores it once deleted; the gate only meant to spare connector-synced files, whose next sync would bring them back. An operator a desk asked to remove a stray reading found no Delete and only Remove from project, which publishes the file organization-wide instead. The rule "authored here versus owned by an external sync" already existed twice — the controlled-record gate on the server and its client mirror — and the project tab carried a divergent third copy; all three now read one predicate: an upload, an agent-written file and a row with no provider recorded are authored, and every other value is a connector whose sync loop owns the row.

ui.tale.dev answers a German or French reader instead of redirecting them to a 404 (#3448)

Opening the component site in a German browser answered 302 Location: /de, and /de was Page not found; a tale_locale=de cookie — set by every reader who ever picked German or French on tale.dev — did the same. The site boots the shared React server from @tale/ui, whose locale negotiation is written for tale.dev and docs.tale.dev, which ship three URL trees; ui.tale.dev ships one English tree, with no locale segment in its routes and no /de or /fr prerendered. The server gains a localeRouting mode: 'path', the default, is today's negotiated three-tree shape and leaves web and docs untouched; 'none', which ui-docs passes, skips negotiation whole — no redirect, no tale_locale cookie the site does not own, no locale Vary on an answer that varies by neither header — and sends a stale /de… or /fr… back onto the tree with a 301, so a bookmark this server once minted still lands on its page. A real-server integration test boots both modes.

The component site's front page is composed like tale.dev (#3449)

The front page of ui.tale.dev, the marketing design language's own shop window, did not speak it: two left edges (every section heading centred where tale.dev aligns to the start), a hard seam under the navigation where the hero wash was painted on the header alone, a product window floating between empty strips, and an empty sixth cell in the card panel. The page is now composed the way tale.dev composes — one top wash on the shell, a left-aligned display hero with a quiet meta line (guide count, both packages, the licence), the stage attached straight under its heading, one left edge throughout, a card panel that spans its cells at every width with each card stating how many guides its section holds (read from the same navigation tree the rail renders, so the numbers cannot drift), a two-column install band and a closing band on the marketing gradient.

Behaviour changes

  • Projects > Knowledge: a row's Delete follows provenance. A file uploaded to the project and a file an agent wrote into it offer Delete (disabled with a reason under a legal hold or on a frozen controlled record, never absent); a file synced from a connector — OneDrive, Google Drive, SharePoint, Confluence, WebDAV — offers none, because the next sync would restore it; remove it at its source. Remove from project and Mark as controlled record are unchanged. The tab stays deliberately narrower than the Knowledge library's rule: a directly selected connector row the library lets you delete is still refused in the project, because the project listing does not carry the fields that rule reads.
  • Two-factor enrolment (the account settings section and the enrolment wall) is unchanged for the time-based codes this deployment registers; an enable answer that carries no TOTP secret shows the enable-failed error instead of advancing to a QR code with nothing behind it. That arm cannot occur today — the guard is a guard, not a reachable flow.
  • The identity provider's client registration — the app's identity door (POST /api/app/identity/clients, admin only) and the CLI's native client lane — sends and stores application_type: web; the read-back that compares a found client against the deployment's policy reads the same field, and a client record that is not an object reads as a configuration conflict rather than skipping the check.
  • The CLI: a retained provisioning intent an older CLI wrote — durable operator state on disk that still carries the client's application type under the provider's old key — is accepted and normalised on resume instead of hard-refusing as "does not match its contract"; every write uses the new key. The native client export verification no longer requires the retired public field.
  • The provider capabilities that arrive with the 1.7 line — DPoP-bound tokens, resource indicators, client assertions, back-channel logout, refresh-token rotation — are present in the schema and not configured: the provider still issues the authorization-code grant only, with an empty audience list and five-minute codes and tokens, and dynamic registration stays closed.
  • ui.tale.dev: a request with a German or French Accept-Language or a tale_locale cookie answers the English page with 200 (was a 302 into a 404); /de answers 301 → / and /fr/docs/components/button 301 → /docs/components/button (were 404); the site sets no tale_locale cookie and no Vary: Accept-Language, Cookie; an unknown path is still a 404. tale.dev and docs.tale.dev keep the negotiated three-tree behaviour — the new server option defaults to it and neither site passes the other mode.
  • ui.tale.dev front page: the composition above — one wash, one left edge, the stage under its heading, a full card grid with per-section guide counts, a two-column install band; two new ICU plural strings (home.heroMeta, home.guideCount) in English, German and French, no key removed.
  • Documentation (English, German and French): the project files page says which rows carry Delete and why a synced row does not; the ui-docs README states the single-tree serving contract and what adding a translated tree would take.
  • The contributor contract (AGENTS.md): a branch, where a repository asks for one, is named for the work — <type>/<kebab-slug> with a commitlint type, or dist/ for published build output — never for the tool that did it.

API contract changes

  • None in this range. The contract stays at 1.20.0: 86 paths, 135 operations, 63 schemas, 167 Error.code values; the shipped openapi.json is byte-identical to 0.5.44's, and X-Tale-Api-Version answers 1.20.0.
  • For the record, because no curated notes said so: 0.5.43 was the first published release to move the contract from 1.19.0 to 1.20.0 (#3438). The one addition is PATCH /api/v1/projects/{id}/tasks/{taskId} with an archived boolean — the REST door can archive and restore a task, which 1.19.0's Task description had recorded as a verb the door lacked; the Task schema's description changes accordingly. Paths, schemas and error codes are otherwise the same set as 1.19.0.
  • MCP: unchanged.

Security

  • The Better Auth family moves to 1.7.5 (#3447) and closes GHSA-p2fr-6hmx-4528 (@better-auth/oauth-provider from 1.4.8 before 1.7.0-beta.4; CVSS 6.4, medium): an access token for an unauthorized audience through a resource indicator not bound to the grant. The workaround the 0.5.33 notes described — validAudiences empty, the authorization-code grant only — stays in place and is no longer what stands between a deployment and the advisory. The dependency-audit and image-configuration lane (bun audit, Trivy) passed on the change; no other advisory is open.
  • The enrolment screens refuse a secret-less two-factor answer (#3447) — narrowed, not asserted, so a future OTP-configured server cannot render an empty QR code.
  • The native client policy is unchanged in substance: PKCE required, consent not skipped, client_secret_post, the authorization-code grant, the code response type, a web application type, the exact scope set and the organization stamp — now read from the renamed field. A client metadata record that is not an object is a conflict.
  • Dependencies: better-auth, @better-auth/core, @better-auth/api-key, @better-auth/oauth-provider, @better-auth/passkey, the adapters and telemetry 1.6.30 → 1.7.5; @better-fetch/fetch 1.3.1 → 1.3.2; the Better Auth packages pin their own nested zod 4.6.5 and jose 6.2.12, and the workspace's own pins are unchanged. No other dependency changes.

Known issues

  • A native OIDC client registered before this release is refused by this release's CLI until its application type is backfilled. Better Auth 1.7 renamed the stored field from type to applicationType; its migrator adds the new column empty and nothing copies the old value, so a client a 0.5.44-or-earlier tale deploy created (a clients entry in the deployment specification) reads back with no application type, and this release's CLI refuses it in both places it looks — the reconcile (Existing native client security policy does not match.) and the credential-export verification (Native credential export verification failed; no credentials were changed.). Proved on a database the 0.5.44 image had booted. No managed deployment in the fleet carries such a client, and a deployment without native clients is unaffected. The remedy, once the new platform image has booted (the column exists only then) and before the deploy's native-client phase is retried, is one statement on the application database, after which both checks pass: UPDATE "oauthClient" SET "applicationType" = "type" WHERE "applicationType" IS NULL AND "type" IS NOT NULL; A boot backfill that does this for every deployment is the follow-up.
  • ui.tale.dev ships one English tree. A German or French preference a reader set on tale.dev is not honoured there, by design of the single tree; adding a translated tree means prerendering it and switching the site's server back to path routing, as its README says.
  • The old oauthClient.type and public columns stay on the table — Better Auth's migrator never drops a column — and nothing in this release reads or writes them.
  • team.memberCount is a constant 0 on every team, kept by the SQL default and never maintained; anything that starts calling Better Auth's own team endpoints has to maintain it first. The Teams surfaces do not read it.
  • The 0.5.42–0.5.44 window has no curated known-issues record. Its fourteen changes: the sandbox vision lane armed for every managed gateway turn (#3436); every entity list led by the same icon and name (#3437); the REST task archive door (#3438); an indexing run ended when its document is released mid-run (#3439); the release pipeline validating and publishing from the tag (#3440, #3441); every nav section opening on its own first page, every content frame on the same inset, every classified chat error labelled on chat health (direct commits); every table with the same footer and the trash frame fixed (#3442); the opt-in compact Claude harness (#3443); pinned Python document libraries baked into the sandbox runtime image (#3444); the runtime's document tools verified on both release architectures (#3446). Two gaps from that window are known: the Settings > Governance > Vision model description (English, German and French) still says a model that already reads images never uses the vision model, which #3436 made inaccurate — the lane is armed for every managed gateway turn, and a model that reads images serves as its own lane model; and 0.5.43's generated list omits the five pull requests it was the first to ship.
  • Unchanged from v0.5.41, where each is described in full: spend history booked before that release is not rewritten and a month-to-date total spans two pricing rules; off-peak and long-context pricing tiers are not modelled; cache prices are not surfaced; a pin to deepseek-v4-flash answers CHAT_MODEL_UNKNOWN; the Moonshot, Vercel and OpenRouter harness doors are declared from vendor documentation; the three lane-fix follow-ups (the Read hook's PDF guard, the resumed-retry replay, Z.ai's unused Anthropic door) are open; a shipped provider whose catalog carries no curated embedding entry is refused as an embedding provider; the custom-provider form's authoring limits and a bare listing's assumptions; tale-vision --thinking disabled is validated against a controlled upstream only; the chat scroll rounds CHAT-F39 and CHAT-F40 are browser-tested for the wheel and the follow latch only; the bun dev runtime-image step was not observed live.
  • Unchanged from v0.5.39, where each is described in full: a knowledge entry the REST door wrote before that release keeps source: "manual"; a scan reuses a robots verdict up to a minute old and a row stored earlier carries no sitemap list; the ask retraction is best-effort and forward-only; the app's own archive stays unfenced; GET /api/v1/teams is read-only and a complete set; the chat content cap counts UTF-16 code units; the nullable on a oneOf branch is the OAS 3.0 spelling; 0.5.38 shipped with generated notes and its four pull requests (#3424–#3427) have no known-issues record.
  • Unchanged from v0.5.37, where each is described in full: ledger rows booked before that release keep the subject they were booked under and a project agent can appear twice in Top assistants across the upgrade; app.usage_events is write-retired, not dropped; nothing in the schema forbids a door string in usage_ledger.user_id; the run list labels a keyed start Started by api-key:…; the GOV-F20 round is manual; llm nodes are unmetered and a run carries no usage or cost.
  • Unchanged from v0.5.36, where each is described in full: automation files: mounts and workflow document.* steps do not apply the team audience; a single-sign-on sign-in with an empty group list revokes nothing and a SCIM group replace overwrites hand-added members silently; the legacy team mirror columns stay; the three GIN indexes of migration 0109 were built without CONCURRENTLY; the team rounds NAV-F6, SET-F18, SET-F19, SET-F42, KNOW-F20, PROJ-F23, PROJ-F24 and CONV-F12 are manual; a team skill's teams list is validated only when it changes; REST Document.teamId stays as the deprecated single-team spelling.
  • Unchanged from v0.5.35, where each is described in full: a frame carries the signed-in session only from a same-site host page and the shell's embedding policy is the union across organizations; revoking a trusted-header key or turning the card off ends no session; the AUTH-F21–AUTH-F24, AUTH-B10 and SET-F41 rounds are manual; approvals have no REST twin; moving a folder has no door and documents already at the root stay there; the auto-retry resumes only a turn that announced its conversation handle; the Google Drive row counts a deployment app from either lane.
  • Unchanged from v0.5.34, where each is described in full: a managed deployment gets the organization-creator behaviour only once its specification declares organizations.creators and a new bundle is applied; the AUTH-B9 and AUTH-F20 rounds are manual; the creator list is matched against sign-in addresses.
  • Unchanged from v0.5.33, where each is described in full: the sign-up gate's first-boot race; the boot catch-up that marks provisioned accounts verified asks nobody; the break-glass administrator's password-rotation, single-sign-on-link and memory-adapter limits; the cross-scope webhook guard governs deliveries from that release on; a site's robots policy upgrades at its next scan; a scan waiting on render capacity takes longer by design; the governance pickers list only providers with an active credential. The dependency advisory that release left open is closed by this one.
  • Unchanged from v0.5.32, where each is described in full: the embedding pacing is proved against a controlled server, its bound is per Tale process, and minTokensPerSecond is a statement nothing verifies; the Kubernetes page's verified scope is one kind cluster, config-data needs RWX or a single node, and Tale ships no Helm chart.
  • Unchanged from v0.5.31, where each is described in full: a managed deployment picks up that release's proxy policy only when a newly prepared bundle is applied; the transcription setting is only as good as the organization's credentials; the six agent-turn fixes are bounded by the pinned Claude Code build they were read from; the 0.5.29 proxy change has been exercised live in TLS_MODE=letsencrypt only; the web tier's backend-URL default lives in the image, not in the generated compose; the scheduled-pack fix does not reach an automation an organization already has; a budget hold covers a turn's first round only; nothing backfills a task timeline.
  • Unchanged from v0.5.20, where each is described in full: the es/co-cc Colombian cédula detector still ships switched off and a locale-agnostic PII toggle still widens national-ID matching to every locale; thinking-block replay on the native Anthropic connector is not done and the live Max-plus-tool-call check is still owed; rag_search embedding calls inside a harness turn are unmetered; the product edit dialog cannot clear a field; the app's skill editor still carries the retired private visibility.
  • Cloud sync, left for later: there is still no Sync now action — the cadence is the fifteen-minute scan, so a reconnected account waits for the next run. A config whose owner leaves the organization is still deactivated silently by a different door, and a source-deleted item is still a status stamp with no bell.
  • Documents indexed before 0.5.27 keep one vector per repeated passage until they are re-indexed; the content hash is unchanged, so only an explicit retry-indexing (or a content change) re-embeds them.
  • The rail's navigation memory has had part of its manual round: the R5 round drove six EN/DE/FR desktop and phone cases covering parts of NAV-F16–NAV-F19; the remaining section, the second-account cases and NAV-B6–NAV-B9 are still unrun.
  • A reply-language directive is a directive: a model may still answer in the prompt's language and nothing on the wire marks a slip.
  • No image input on the REST chat send. A vision model reads an image over REST only on a thread the app continued with an image attachment; the design of an attachments field on the send is recorded as contract debt.
  • No REST door authors or deploys an automation — POST /automations answers 405 by design. Build and deploy in the app, or over the MCP endpoint's save_automation and deploy_automation; the REST key lists, reads, runs, answers asks and wires triggers.
  • The x-tale-pagination extension is a declaration on the OpenAPI document; generated clients that do not read vendor extensions still branch on the two cursor names until cursor is retired.
  • The app's zip upload of a skill bundle rewrites the bundle and moves updatedAt even when the zip is byte-identical, where PUT /skills/{slug} writes nothing.
  • A tool call the reply cap cut keeps input: {} on the stored tool-call part; the raw text the model emitted is still not on the transcript.
  • Folder names written before 0.5.24 keep their bytes; a sync engine's hub-path lookup can create an NFC twin beside a legacy NFD folder. No backfill ships.
  • Two bounded document readers still filter after their cut; both report an honest truncated, so a caller can tell the answer was cut.
  • Behind a Docker-published port, every IPv6 client arrives as the bridge gateway's address and shares one per-address rate-limit bucket and one audit address until the daemon runs with ip6tables and the reverse proxy's network is IPv6-enabled — an operator item, documented on the Own Compose page.
  • Recorded as contract debt, each with its design in the ledger: a queued send is invisible on the message list until a worker opens it; a webhook delivery the deployed inputs schema refuses moves no trigger stamp; the MCP run_deployed tool keys its idempotency apart from start_run and REST; a page is fetched three to four times per scan; a cancelled run answers trace: null and effects: null where a failed run answers both; approvals have no REST twin; a task can be archived and restored over REST since 0.5.43 but still not deleted; a webhook bind does not say whether the deployed inputs schema admits a delivery; an exhausted repeatUntil is only a trace note; Website carries no scanStartedAt and the crawler has no page cap, path filter or stop verb of the caller's; website search has no dense leg and its substring fallback stamps score: 0; no Idempotency-Key on the task start; no queue position on a queued send; a corrupt Office document still fails as indexer_error and is retried five times where a PDF lands malformed; no /.well-known/security.txt; no changelog feed on tale.dev; no SDK, collection or per-code table beyond the Error.code enum; GET /notifications rows carry type as a free string and nothing pushes them to a machine caller; a skill keeps no version history on the machine door; the per-task circuit breaker is not built; the messages a conversation snapshot applied are readable only in the app; a run carries no usage or cost.

Migration notes

  • No numbered migration. The application database stays at 0112; the knowledge database is unchanged. db/migrate.ts and auth/auth.ts change, but neither adds a .sql file.
  • Better Auth's own migrator runs at boot, inside the app-wide advisory lock, after the numbered files, additive only — it creates missing tables and adds missing columns and never drops or alters one. Against a 0.5.44 database it plans three tables and columns on seven (verified with the release commit's planner on a database the 0.5.44 image had booted): the tables oauthResource, oauthClientResource and oauthClientAssertion; the columns oauthClient.applicationType, .clientDiscoveryId, .clientCredentialsScopes, .backchannelLogoutUri, .backchannelLogoutSessionRequired, .jwks, .jwksUri, .dpopBoundAccessTokens; oauthAccessToken.authorizationCodeId, .resources, .requestedUserInfoClaims, .revoked, .confirmation; oauthRefreshToken.authorizationCodeId, .resources, .requestedUserInfoClaims, .rotatedAt, .rotationReplayResponse, .rotationReplayExpiresAt, .confirmation; oauthConsent.resources, .requestedUserInfoClaims; jwks.alg, .crv; team.memberCount; teamMember.membershipKey. Every one is nullable except team.memberCount (NOT NULL), which the boot step right after — ALTER TABLE IF EXISTS "team" ALTER COLUMN "memberCount" SET DEFAULT 0, every boot, idempotent — gives its default, so a plain-SQL team insert that names no count lands; a raw team insert and a raw teamMember insert were both exercised after the roll. It is not a numbered migration for the same reason the provisioned-account catch-up is not: the numbered files run before Better Auth's tables exist.
  • Rolling-deploy safe. The previous image neither reads nor writes any of the new columns and tables; the new image's schema probe is off, so neither side logs a mismatch while the other is mid-roll; the advisory lock serialises concurrently booting containers.
  • No environment variable is added or removed; .env.example is unchanged. No scheduled job, audit action, error code, catalog, provider definition or platform message key changes; the ui-docs site gains two message keys in English, German and French. No proxy, db, object-store or compose.yml change.
  • Images: the platform image (the identity provider, the boot, the project tab, the shared provenance predicate), the docs image (one page in three languages), the ui-docs image (the front page, the server's single-tree mode) and the web image carry source changes — the last three because they bundle @tale/ui's shared React server, which gains the localeRouting option; web and docs keep the default mode, so their behaviour is unchanged. The sandbox image carries no source change of its own but is rebuilt, because the workspace lockfile it installs from changed. The proxy, db, sandbox-runtime, sandbox-egress, sandbox-buildkitd and sandbox-llm-gateway images carry no source change. No image in the stop-gated tier changes — a plain tale deploy is the whole upgrade: no --stop, no downtime window.
  • The CLI changes in this range — the native client lane's field rename and the retained-intent tolerance — and so do the reference tree it embeds (the shared provenance predicate) and the lockfile, so the release executables are rebuilt and differ from 0.5.44; they report 0.5.45. Move a managed deployment's CLI pin and platform pin together; for a deployment with native clients this release requires it: a 0.5.44 CLI against a 0.5.45 backend requires the public field and reads the application type from a field the backend no longer exposes, and a 0.5.45 CLI against a 0.5.44 backend expects an application_type the backend does not send — either mixed pair refuses the native client work. A deployment without native clients is unaffected by the pairing.
  • @tale/ui and @tale/marketing-ui are pinned by this release as the ui-v0.5.45 and marketing-ui-v0.5.45 tags on their snapshot branches; a consumer outside the monorepo installs "@tale/ui": "github:tale-project/tale#ui-v0.5.45". @tale/ui changes in this range (#3448: stripLocalePrefix and the localeRouting option on startReactServer), so ui-v0.5.45 differs from ui-v0.5.44; @tale/marketing-ui does not change, so marketing-ui-v0.5.45 is content-identical to its predecessor.

Upgrading

  • On the 0.5 line (0.5.0 – 0.5.44; there is no 0.5.42 deployment to be on):

    tale update
tale deploy

    Better Auth's migration and the memberCount default are applied at boot. Nothing in this release needs --stop. A deployment crossing 0.5.41 runs migration 0112 at boot as well; one crossing 0.5.39 runs migration 0111, one crossing 0.5.38 runs that release's 0108_approvals_one_pending_conversation_draft.sql, one crossing 0.5.37 runs migration 0110, one crossing 0.5.36 runs migration 0109, one crossing 0.5.35 runs migration 0108 (0108_trusted_header_keys.sql) and Better Auth's session column, and one crossing 0.5.33 runs migration 0107. A deployment crossing from a version older than 0.5.29 should read that release's notes, which do: its proxy image change is only applied by a --stop deploy.

  • Before you upgrade, check for native OIDC clients. A deployment whose specification declares clients and whose clients were created by a CLI older than this release needs the one-statement backfill under Known issues after the new image boots; plan for the deploy's native-client phase to refuse once. Nothing else needs re-pointing: no catalog, model, environment variable or contract field changes in this range.

  • Managed deployments move by pinning the CLI and the runtime to this release's commit, preparing a new bundle and applying it with the pinned CLI — see Managed deployments on the CLI install page. The bundle's backend-local phases run under the interpreted CLI (cli/tale.mjs) that the setup-cli action and bun run --filter @tale/cli build produce beside the executable; the executable from the release page has no interpreted bundle beside it and cannot prepare a managed bundle. On a Linux x64 host whose CPU lacks AVX2, pass linux-baseline: 'true' to the setup-cli action so the bundle embeds the baseline executable.

  • New install:

    curl -fsSL https://raw.githubusercontent.com/tale-project/tale/main/scripts/install-cli.sh | bash
mkdir tale-05 && cd tale-05
tale init
tale deploy

    On a CPU without AVX2 the downloaded executable aborts with Illegal instruction; build it from source with bun run build:linux-baseline in tools/cli.

What's Changed

Full Changelog: v0.5.44...v0.5.45

Contributors

larryro and yannickmonney
Assets 8
Loading