test(docker): add postgres-prepared-pipeline-reorder to prestart-map

[robobun]

Problem

test/js/sql/postgres-prepared-pipeline-reorder.test.ts reported 18s wall time on debian 13 aarch64 in build #81338. The four tests in the file take ~80ms on a release build; the rest is postgres_plain container cold-start.

The coordinator log for that shard shows why:

[67/281] test/js/sql/postgres-prepared-pipeline-reorder.test.ts
coordinator: ensuring postgres_plain          t=1785028906850
coordinator: postgres_plain ready             t=1785028924733   (+17.9s)
Container ready via docker-compose            t=1785028924735
....                                          t=1785028924817   (tests: 82ms)

Other shards of the same build see coordinator: postgres_plain ready (cached) and the file finishes in <1s.

Cause

test/docker/prestart-map.mjs is read by two consumers:

• scripts/runner.node.mjs sorts matching test files toward the end of the shard so container cold-start overlaps with the non-docker tests that run first.
• test/docker/coordinator.ts pre-warms every mapped service at shard launch.

This test file was added in #33627, right after the map was last touched in #33622, so it matches no prefix. In a shard where it is the only (or earliest-scheduled) postgres_plain test, the runner does not defer it and the coordinator does not pre-warm the container, so the file's beforeAll pays the full cold-start.

Fix

• Add js/sql/postgres-prepared-pipeline-reorder to prestart-map.mjs.
• Flip the file's describeWithContainer to concurrent: true. Each test owns its own max: 1 SQL instance, issues only SELECT with parameters, and shares no state, so the four connect + warm-up round trips can overlap. This matches the existing pattern in sql-mysql.test.ts / sql-mysql.helpers.test.ts / sql-mysql.auth.test.ts.

The assertions are already strong (toEqual on full row shapes, no exit-code-only checks, no "absence of panic" checks), so nothing to tighten there.

postgres-datestyle.test.ts (#35112) has the same prestart-map gap; #35738 is already reworking that file to drop the container dependency entirely, so it is left alone here.

Timing

Debug+ASAN, local, warm postgres via BUN_TEST_SERVICE_postgres_plain (so the env-override path never paid the cold-start either; this measures only the in-file change):

	before	after
bun bd test wall time	4.47s	3.1s

CI (build #81338, debian 13 aarch64): 18s, all of it cold-start. With the map entry the coordinator pre-warms postgres_plain at shard launch and the runner schedules this file after the non-docker tests, so the expected wall time is the same <1s every other mapped postgres file in that build already reports.

Verification

$ bun bd test test/js/sql/postgres-prepared-pipeline-reorder.test.ts
(pass) postgres > a prepared-statement execute does not jump a queued unwritten simple query
(pass) postgres > a prepared-statement execute does not jump a queued unwritten prepare
(pass) postgres > prepared executes do not jump multiple queued unwritten prepares
(pass) postgres > mixed burst of prepared and new statements returns every row in order
 4 pass, 0 fail  (5/5 consecutive runs under describe.concurrent)

This is a test-infrastructure change with no src/ modification; there is no fail-before state to demonstrate.

---

[stamp-90s] gate passed · iteration 0 · 2 files touched

passes on PR (with fix)

Test-only change.

Debug/ASAN (expected pass):
$ bun bd test 'test/js/sql/postgres-prepared-pipeline-reorder.test.ts'
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test test/js/sql/postgres-prepared-pipeline-reorder.test.ts
bun test v1.4.0 (ddb7553b3)

test/js/sql/postgres-prepared-pipeline-reorder.test.ts:
Container ready via docker-compose: postgres_plain at 127.0.0.1:5432
(pass) postgres > a prepared-statement execute does not jump a queued unwritten prepare [603.11ms]
(pass) postgres > prepared executes do not jump multiple queued unwritten prepares [401.14ms]
(pass) postgres > a prepared-statement execute does not jump a queued unwritten simple query [343.80ms]
(pass) postgres > mixed burst of prepared and new statements returns every row in order [447.01ms]

 4 pass
 0 fail
 4 expect() calls
Ran 4 tests across 1 file. [4.64s]
Exit: 0

diff hotspot

test/docker/prestart-map.mjs                           | 1 +
 test/js/sql/postgres-prepared-pipeline-reorder.test.ts | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

gate history · 1 passed · 0 rejected · iteration 0

evidence per changed file

file                                                    reads  edits  tests
test/docker/prestart-map.mjs                                1      1      0
test/js/sql/postgres-prepared-pipeline-reorder.test.ts      1      1      0

self-review · no surviving concerns

23 concerns were raised and did not survive verification.

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 3 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 1b0a8349-211e-4735-9d04-835f4fddd16b

📥 Commits

Reviewing files that changed from the base of the PR and between 44f6469 and ddb7553.

📒 Files selected for processing (2)

• test/docker/prestart-map.mjs
• test/js/sql/postgres-prepared-pipeline-reorder.test.ts

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

^{Updated 8:06 AM PT - Jul 26th, 2026}

❌ @robobun, your commit ddb7553 has 2 failures in Build #82338 (All Failures):

• test/cli/run/no-orphans.test.ts - code 1 on 🍎 26 aarch64
• 📦 Binary size — 12 over 0.50 MB

target	this build	canary: main #79916
		size	Δ
❌ bun-darwin-aarch64	58.13 MB	57.58 MB	+564.9 KB
❌ bun-darwin-x64	63.48 MB	62.95 MB	+544.5 KB
❌ bun-linux-aarch64	70.98 MB	70.42 MB	+576.0 KB
❌ bun-linux-x64	72.47 MB	71.95 MB	+528.0 KB
❌ bun-linux-aarch64-musl	64.88 MB	64.32 MB	+576.0 KB
❌ bun-linux-x64-musl	66.98 MB	66.45 MB	+544.0 KB
❌ bun-linux-aarch64-android	78.47 MB	77.97 MB	+512.0 KB
❌ bun-linux-x64-android	80.62 MB	80.10 MB	+529.2 KB
❌ bun-freebsd-x64	83.07 MB	82.56 MB	+528.0 KB
❌ bun-freebsd-aarch64	84.84 MB	84.31 MB	+544.0 KB
❌ bun-windows-x64	80.26 MB	79.70 MB	+570.5 KB
❌ bun-windows-aarch64	70.86 MB	70.34 MB	+533.0 KB

Add [skip size check] to the commit message if this increase is intentional.

---

🧪   To try this PR locally:

bunx bun-pr 35912

That installs a local version of the PR into your bun-35912 executable, so you can run:

bun-35912 --bun

[claude]

LGTM — straightforward test-infra change adding a missing prestart-map entry and enabling concurrent describe.

What was reviewed:

• Verified describeWithContainer accepts concurrent and routes to describe.concurrent (harness.ts:1099/1156); matches existing usage in the three sql-mysql*.test.ts files.
• Confirmed each test owns its own await using sql = new SQL({ max: 1 }), awaits container.ready, and only issues stateless SELECTs — no shared state to make concurrency unsafe.
• prestart-map entry matches the format and service name of its neighbors; a missing entry only means slower cold-start, so worst case is no-op.

Extended reasoning...

Overview

Two-line change across two test-only files: adds js/sql/postgres-prepared-pipeline-reorder → ["postgres_plain"] to test/docker/prestart-map.mjs, and flips the file's describeWithContainer to concurrent: true. No src/ changes.

Security risks

None. This touches CI test scheduling metadata and a test-runner concurrency flag. No user-facing code, no auth/crypto/permissions.

Level of scrutiny

Low. The prestart-map is a hand-maintained hint table whose header comment explicitly says a missing entry is "correct, just slower" — so a wrong entry can at worst pre-warm an unused container. The concurrent: true change is the only thing that could affect test correctness, and I verified: (1) the harness supports the option and it's already used identically in sql-mysql.test.ts, sql-mysql.helpers.test.ts, and sql-mysql.auth.test.ts; (2) each of the four tests creates and disposes its own max: 1 SQL instance via await using, awaits container.ready independently, and issues only parameterized SELECT statements against the shared postgres container — no DDL, no shared connection, no mutable module-level state. Running them concurrently cannot change what each test observes.

Other factors

The PR description shows 5/5 consecutive passing runs under describe.concurrent, and the map entry follows the exact format of the six neighboring js/sql/postgres-* entries. The known sibling gap (postgres-datestyle.test.ts) is explicitly called out as being handled in #35738. No outstanding reviewer comments.

[robobun]

Self-review complete, no surviving concerns.

CI on ddb7553 (build #82338, 192/196 lanes done): every test lane ran the changed file green. The two red lanes are unrelated to this diff:

• :package: binary-size compares every target against the canary baseline from main #79916; this diff touches two test files and zero compiled bytes, so the ~530 KB delta is main's own growth since that canary.
• test/cli/run/no-orphans.test.ts on darwin 26 aarch64 timed out in bun run --no-orphans (perl): fast-exit intermediate; the same test passed on retry on darwin 14 x64. Unrelated to the docker prestart-map or the postgres test.

On debian 13 aarch64 (the 18s lane from build #81338) the changed file now reports 6.38s, and that number is inflated by the modified-tests-first ordering that runs it at the top of the shard only for this PR's build; on a normal main run the coordinator pre-warm plus docker-defer ordering put it at the end of the shard where postgres_plain is already (cached).

Ready to merge.