V7.3 minor release

src/content/docs/en/guides/integrations-guide/cloudflare.mdx

@@ -465,16 +465,20 @@ When using these handlers in your worker entrypoint, they replace the functional
 
 For use with [`astro/fetch`](/en/reference/modules/astro-fetch/). The `cf()` function imported from `@astrojs/cloudflare/fetch` receives a [`FetchState`](/en/reference/modules/astro-fetch/#fetchstate), the Cloudflare `env`, and the `ExecutionContext`. It returns a `Response` for static asset hits, or `undefined` when the request should continue to Astro rendering:
 
+<p><Since v="14.3.0" pkg="@astrojs/cloudflare" /></p>
+
+Pass the same `FetchState` and the response from your Astro pipeline to `finalize()` before returning it. This applies cookies produced during rendering and the adapter's default Cloudflare CDN cache headers to the response.
+
 ```ts title="src/worker.ts"
 import { astro, FetchState } from 'astro/fetch';
-import { cf } from '@astrojs/cloudflare/fetch';
+import { cf, finalize } from '@astrojs/cloudflare/fetch';
 
 export default {
   async fetch(request: Request, env: Env, ctx: ExecutionContext) {
     const state = new FetchState(request);
     const asset = await cf(state, env, ctx);
     if (asset) return asset;
-    return astro(state);
+    return finalize(state, await astro(state));
   },
 };
 ```
@@ -485,6 +489,8 @@ export default {
 
 For use with [`astro/hono`](/en/reference/modules/astro-hono/). The `cf()` function imported from `@astrojs/cloudflare/hono` returns a Hono middleware that reads `env` and `executionCtx` from the Hono context automatically:
 
+In `@astrojs/cloudflare` v14.3.0 and later, this middleware also finalizes the response after downstream Hono handlers run. Cookies produced during rendering and the adapter's default Cloudflare CDN cache headers are applied automatically.
+
 ```ts title="src/worker.ts"
 import { Hono } from 'hono';
 import { actions, middleware, pages, i18n } from 'astro/hono';

src/content/docs/en/reference/cache-provider-reference.mdx

@@ -371,10 +371,45 @@ The incoming `request` is passed as a second argument so a provider can read the
 
 <p>
 
-**Type:** <code>(context: \{ request: Request; url: URL; waitUntil?: (promise: Promise\<unknown\>) => void \}, next: <a href="/en/reference/modules/astro-middleware/#middlewarenext">MiddlewareNext</a>) => Promise\<Response\></code>
+**Type:** <code>(context: \{ request: Request; url: URL; waitUntil?: (promise: Promise\<unknown\>) => void; logger: <a href="/en/reference/logger-reference/#astroruntimelogger">AstroRuntimeLogger</a> \}, next: <a href="/en/reference/modules/astro-middleware/#middlewarenext">MiddlewareNext</a>) => Promise\<Response\></code>
 </p>
 
-Intercepts requests to implement runtime caching. The `context` includes a `waitUntil()` function (when available in the runtime) for background work such as stale-while-revalidate.
+An optional hook that intercepts a request before Astro generates the matching route. It receives a `context` object as its first argument and a callback to call the `next()` middleware in the chain.
+
+The `context` contains the following properties:
+- `request`: the incoming [`Request`](https://developer.mozilla.org/en-US/docs/Web/API/Request) object.
+- `url`: a normalized [URL](https://developer.mozilla.org/en-US/docs/Web/API/URL) derived from the request.
+- `waitUntil()`: when available in the runtime, a function to define background work, such as revalidating a stale cache entry.
+- `logger`: since Astro v7.3.0, a [`logger`](/en/reference/api-reference/#logger) instance that respects the [configured logging destination](/en/reference/configuration-reference/#logger-options)
+
+The following example implements a minimal `onRequest()` hook that logs each URL added to the cache:
+
+```ts title="my-provider/runtime.ts" ins={7-17}
+import type { CacheProviderFactory } from 'astro';
+
+const factory: CacheProviderFactory = (config) => {
+  const cache = new Map();
+  return {
+    name: 'my-cache-provider',
+    async onRequest({ request, url, waitUntil, logger }, next) {
+      if (request.method !== 'GET') return next();
+
+      const cached = cache.get(url);
+      if (cached) return cached;
+
+      const response = await next();
+      cache.set(url, response.clone());
+      logger.info(`Cached response for ${url}.`);
+      return response;
+    },
+    async invalidate() {
+      // ...
+    },
+  };
+};
+
+export default factory;
+```
 
 #### `CacheProvider.invalidate()`
 

src/content/docs/en/reference/cli-reference.mdx

@@ -196,25 +196,7 @@ The following hotkeys can be used in the terminal where the Astro development se
 - `o + enter` to open your Astro site in the browser.
 - `q + enter` to quit the development server.
 
-<h3>Flags</h3>
-
-<p><Since v="7.0.0" /></p>
-
-The command accepts [common flags](#common-flags) and the following additional flags.
-
-#### `--ignore-lock`
-
-<p><Since v="7.1.0" /></p>
-
-Starts the dev server without checking or writing the lock file used to detect other running dev servers. This allows a new dev server to start alongside one that's already running for the same project, instead of erroring.
-
-```shell
-astro dev --ignore-lock --port 4322
-```
-
-The new server is not tracked by the [`stop`, `status`, or `logs` subcommands](#common-subcommands).
-
-When combined with `--background` (including when triggered by an AI coding agent) or `--force`, an error is thrown, as both rely on the lock file.
+The command can be combined with the [common flags](#common-flags) and [common subcommands](#common-subcommands) to further control the dev experience.
 
 ## `astro build`
 
@@ -240,7 +222,7 @@ The following hotkeys can be used in the terminal where the Astro preview server
 - `o` + `enter` to open your Astro site in the browser.
 - `q` + `enter` to quit the preview server.
 
-The `astro preview` command can be combined with the [common flags](#common-flags) documented below to further control the preview experience. Since v7.2.0, it also accepts the [`--background` flag](#--background) and the [`stop`, `status`, and `logs` subcommands](#common-subcommands) to manage a background preview server.
+The command can be combined with the [common flags](#common-flags) and [common subcommands](#common-subcommands) to further control the preview experience.
 
 ## `astro check`
 
@@ -560,6 +542,20 @@ astro dev --background --force
 
 Enables [JSON logging](/en/reference/logger-reference/#loghandlersjson), which is useful for machine-readable output.
 
+### `--ignore-lock`
+
+<p><Since v="7.1.0" /></p>
+
+Prevents checking for the existence of a lock file and the need to write one. This allows a new dev server or, since v7.3.0, a preview server to start alongside an already running server, instead of erroring.
+
+```shell
+astro dev --ignore-lock --port 4322
+```
+
+The new server is not tracked by the [common subcommands](#common-subcommands).
+
+When combined with [`--background`](#--background) or [`--force`](#--force-string), an error is thrown, as both rely on the lock file.
+
 ## Global flags
 
 Use these flags to get information about the `astro` CLI.