Ryan Malloy
ac9075ca9a
Last of the untested surface: pipelined executemany, scrollable cursors, and smart LOBs. One bug, in the first. executemany builds all its BIND+EXECUTE PDUs after the PREPARE and before anything is drained — that batching is what makes the pipeline fast. If encoding a row raises there (a value the connection's codec cannot represent), the exception escaped without sending the RELEASE, leaking the prepared statement. The next PREPARE collided with it and every later call on the connection failed with an error pointing at the previous SQL. Same failure as 2026.08.31.2, in a sibling path. _execute_dml_with_params has guarded this exact case for the single-row path for a long time; the pipelined path was never given the same treatment. That is the recurring shape of these bugs: a hazard understood in one place and not carried to the code beside it. What the fuzzer found sound, which is the larger part of the result: executemany constraint failures — duplicate-key and NOT NULL at first/mid/last of batches from 2 to 1000 rows all recover, and COUNT(*) always agrees with a full fetch, so the drain-N-responses invariant holds under partial failure. Scrollable cursors — fetch_first/last/prior/relative/absolute correct at 0, 1, 2, 5, 50, 300 rows, including off both ends (None, not a wrap or a crash) and a full forward walk after arbitrary positioning. Twenty abandoned scroll cursors leak nothing. Smart LOBs — round-trip at 0, 1, 255, 256, 1023, 1024, 4095, 4096, 65535, 65536 bytes, straddling the 4096-byte SQ_FILE chunk and the 64K mark, plus recovery from failed reads. Still not fuzzed, stated plainly: TLS is handshake-tested against a self-signed local socket, not a real Informix TLS listener (that needs server-side keystore + onconfig SSL setup absent from the test containers). The SQLI layer above the socket is identical either way. 399/399 integration on 15, 14.10 and 12.10 (was 356).
Starlight Starter Kit: Basics
npm create astro@latest -- --template starlight
🧑🚀 Seasoned astronaut? Delete this file. Have fun!
🚀 Project Structure
Inside of your Astro + Starlight project, you'll see the following folders and files:
.
├── public/
├── src/
│ ├── assets/
│ ├── content/
│ │ └── docs/
│ └── content.config.ts
├── astro.config.mjs
├── package.json
└── tsconfig.json
Starlight looks for .md or .mdx files in the src/content/docs/ directory. Each file is exposed as a route based on its file name.
Images can be added to src/assets/ and embedded in Markdown with a relative link.
Static assets, like favicons, can be placed in the public/ directory.
🧞 Commands
All commands are run from the root of the project, from a terminal:
| Command | Action |
|---|---|
npm install |
Installs dependencies |
npm run dev |
Starts local dev server at localhost:4321 |
npm run build |
Build your production site to ./dist/ |
npm run preview |
Preview your build locally, before deploying |
npm run astro ... |
Run CLI commands like astro add, astro check |
npm run astro -- --help |
Get help using the Astro CLI |
👀 Want to learn more?
Check out Starlight’s docs, read the Astro documentation, or jump into the Astro Discord server.