--- title: v0.9.0 url: https://citry.dev/releases/v0.9.0/ description: "What changed in citry v0.9.0." --- # v0.9.0 Citry 0.9.0 states the order in which a page's scripts and `onServerRender` callbacks run, and what happens when one of them fails; see [When scripts run](https://citry.dev/advanced/js-and-css-dependencies/#when-scripts-run). A component script that throws now keeps the page's Vue app from starting, and a third-party script that fails to load, such as one an ad blocker refuses, no longer keeps the Vue app from starting on a page served through a web framework integration. Pages now link Citry's runtimes by a URL that holds a hash of the file, so a deploy needs the cache steps in the upgrade notes. Several changes can break code that worked: `Citry(...)`, `CitrySettings`, `LintSettings` and `URLRoute` take their options by name, `URLRoute` no longer takes `extra=`, a `URLRoute` path with no text between two parameters, such as `"{year}{month}"`, raises an error when your app starts, a component cannot be named `lazy`, `teleport`, `transition` or `suspense`, a template whose `v-for` alias or `v-slot` pattern starts with `$`, `_` or `citry` fails to load, and `Events` classes can no longer set `_topics`. Citry now checks event data on threads of its own and allows 64 levels of nesting. Upgrade citry-lsp to 0.4.0 or later, and citry-ui to 0.5.0 or later if you use it, at the same time. Citry imports on Pyodide again. The upgrade notes below list what can fail or change. ## Upgrading from 0.8.x - **Put text between two route parameters:** a `URLRoute` path such as `"{year}{month}"` now raises `ValueError` naming the route when your app starts, in `asgi_app()`, `wsgi_app()`, the Flask and FastAPI `mount()`, and Django's `urlpatterns()`. Before, it matched, and the first parameter took all but the last character. Citry cannot tell where one value ends and the next begins, so write `"{year}-{month}"` or another separator. ([details](https://citry.dev/advanced/extensions/#separate-two-parameters)) - The same error comes from a parent route whose path ends in a parameter and a child whose path starts with one, such as `"files/{name}"` with `"{ext}"`, because a child's path is added to its parent's as plain text. The message names both routes. End the parent's path with `/`, or start the child's path with text such as `.`. - Routes with text between their parameters, such as `"files/{name}.{ext}"`, match the same paths with the same values as before. - **A component script that throws now keeps the Vue app from starting:** if a component's `js` throws while it runs, or has a syntax error, the page's Vue app does not start, and the console names the component. Before, the page usually started while the error showed in the console. Fix the script, or catch the error inside it when it is expected, for example when an optional browser feature is missing. The page's `error` event still receives the original error. - **A third-party script that fails to load no longer stops the page:** on a page served through a web framework integration, a dependency file or extension script from another origin that fails to load (an ad blocker, a content security policy, a failed integrity check, or a network error) is skipped with a console warning, and the app starts. Citry cannot tell your own CDN from a third party, so this holds for every file from another origin. Serve a file the page must not run without, such as a consent manager, from your own origin. - **`onServerRender` callbacks after a server render now run children before their parent, and siblings in the order they first mounted,** as on the first mount. Before, they ran in the order the server's response listed the components, which often put the parent first. If your code relied on that, check it against the new order. citry-ui 0.4.0 and earlier relied on the old order, so upgrade citry-ui to 0.5.0 or later. - **A callback that throws on the first mount now stops the callbacks after it,** as it already did after a server render. Catch an error you expect inside the callback. - **Extension scripts that register a browser plugin now run before component scripts on every interactive page.** Before, a page written without a web framework integration ran them after. If you write an extension whose plugin script reads a value a component script sets, read it later, for example inside a callback. - **Citry runs your validators, State serializers and `__post_init__` methods on its own threads:** this covers event data and State, and your request thread waits for them. They can read the request's context variables, but a value stored with `threading.local` is unset there, and a context variable a validator sets does not reach your handler. A validator that uses Django's database gets a separate connection, which stays open while the thread lives and does not see rows the request wrote in an unfinished transaction. A write from it waits for that transaction. A validator must not wait for a lock that the request's thread holds, or, under gevent or eventlet, for anything another greenlet holds ([details](https://citry.dev/security/#check-event-data)). - **Raise the stack size you set for request threads to 2 MiB:** if you followed the 0.8.0 advice and call `threading.stack_size(1024 * 1024)` before your server starts its threads, change it to `threading.stack_size(2 * 1024 * 1024)`. Your handler, and a Pydantic `Kwargs`, `Slots` or `TemplateData` class that a render builds from event data, still get the checked data on your server's threads, and code of yours that walks it level by level needs the room ([details](https://citry.dev/security/#check-event-data)). - **A page can outlive the runtime it links:** pages now link Citry's runtime by a URL that changes with each release (see Changed). When a page rendered before a deploy names a runtime that neither the browser nor a shared cache still holds, the page keeps its server HTML, its interactive components do not start, and the browser console shows `Citry could not load its runtime: `. Reloading the page fixes it, unless a cache serves the whole page (next item). - **Clear whole-page caches when you deploy, and give every worker the same cache during rolling deploys:** a page cached before a deploy names the old runtime's URL. During a rolling deploy, give every worker the same cache backend, or use sticky sessions. See [Deploy a Citry upgrade](https://citry.dev/advanced/web-frameworks/#deploy-a-new-version). - **Fixed app ids get a new script hash:** if you set `id_generator` so the script that starts a page's Vue app has the same CSP hash on every response, that hash now also changes when Citry's runtime file changes. Take the hashes from `csp_script_hashes`, as before. - **Interactive renders now write to your cache:** with a cache backend set, every render that links the runtime by URL, fragments included, makes sure the runtime is stored there, checking at most once a minute per process. A cache backend error therefore fails the render. Citry calls the backend's `set` with `ttl=` as a keyword argument, so a custom backend's `set` must accept it under that name. - **Rename a component called `lazy`, `teleport`, `transition` or `suspense`:** Citry keeps these names for built-in tags it plans to add, so a component class named `Teleport`, or one given one of these names through `name` or `register()`, now raises `AlreadyRegistered` when it is defined or registered. A component library that contains one raises `ValueError`. Rename it, for example to `TeleportTarget`, and update the tags in your templates. Longer names that contain one of these words, such as `LazyCard`, still work ([reserved names](https://citry.dev/reference/builtins/#reserved-names)). - **Event data for a plain class or dataclass now has the 64-level nesting limit:** when an event's `data` class is a plain class, a dataclass or a Pydantic dataclass, data that nests more than 64 of its objects inside each other now gets a 422 that says the data is nested too deeply, as a Pydantic model's data already did. Before, Citry's own check of such a class did not count levels. If valid data nests this deeply, flatten the data. - **Pass the options of `Citry(...)`, `CitrySettings`, `LintSettings` and `URLRoute` by name:** these now raise `TypeError` for an argument passed by position, so an option added later cannot change what your call means. `URLRoute` still takes the path and the handler by position. ```python Citry(extensions=[MyExtension]) # not Citry([MyExtension]) # the path and the handler stay positional URLRoute("status", status, name="status") ``` - **Remove `extra=` from `URLRoute`:** Citry never read it, and passing it now raises `TypeError`. If you used it to carry your own data, keep that data where the handler can reach it, for example in a closure. - **Delete `_topics` from your `Events` classes and from `extensions_defaults["events"]`:** Citry did not use it. A component that sets it now raises `ValueError` when the class is defined, and `Citry(...)` raises it for the default. - **A template with a reserved name in `v-for` or `v-slot` fails to load:** Citry now refuses a `v-for` alias, or a `v-slot` or `#name` pattern on a Vue component or `