max / makenotwork

Allow large_stack_arrays where sqlx::migrate! embeds the directory This is what actually failed the 0.11.8 clippy gate, at all three sqlx::migrate! sites. The lint is new because the array is: the macro embeds every migration as one literal, so it measures the whole migrations/ directory, and that crossed the 16KB threshold when the mailing-list tables landed. Nothing about the call sites changed. Allowed rather than worked around. The array is the point of the macro, it is built once at startup, and the alternative is discovering migrations at runtime, which is strictly worse for a service that must not start against the wrong schema. Worth knowing for the next time a gate goes red on a lint nobody touched: the clippy log at /logs/{version}/{gate} is keyed by version and not by run, so at 0.11.8 it holds several runs' output concatenated. The section that matters is the one whose workdir path carries the sha you built. Reading the top of that file sends you to fix errors a previous commit already fixed, which is what happened here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: Max Johnson <me@maxj.phd> · 2026-08-06 16:04 UTC

Signed with PGP, not checked

Commit: 3fa5dc180f20b7abaff2fa7ba1a0bfff9aba9997

Parent: 5c7ebea

2 files changed, +21 insertions, -0 deletions

M server/src/main.rs +11

			@@ -176,6 +176,17 @@
176	176		// Run migrations, exit cleanly (code 2) on failure instead of panicking.
177	177		// This prevents systemd from crash-looping on migration errors (e.g. version
178	178		// conflicts after a bad deploy). WAM ticket alerts the operator.
	179	+	//
	180	+	// `sqlx::migrate!` embeds every migration as one array literal, so the lint
	181	+	// measures the whole `migrations/` directory. It crossed 16KB when the
	182	+	// mailing-list tables landed, which is why this is new and why it is not a
	183	+	// finding: the array is built once at startup and the alternative is
	184	+	// runtime migration discovery, which is strictly worse for a service that
	185	+	// must not start against the wrong schema.
	186	+	#[allow(
	187	+	clippy::large_stack_arrays,
	188	+	reason = "sqlx::migrate! embeds the whole directory"
	189	+	)]
179	190		if let Err(e) = sqlx::migrate!("./migrations").run(&db).await {
180	191		tracing::error!(error = %e, "Migration failed, exiting without restart");
181	192

M server/tests/harness/db.rs +10

			@@ -69,6 +69,15 @@
69	69		const TEMPLATE_LOCK_KEY: i64 = 0x6D6E_775F_7470_6C00; // "mnw_tpl\0"
70	70
71	71		/// Latest migration version embedded in this binary (head of `migrations/`).
	72	+	///
	73	+	/// `sqlx::migrate!` embeds every migration as one array literal, so
	74	+	/// `large_stack_arrays` measures the whole `migrations/` directory. It crossed
	75	+	/// the 16KB threshold when the mailing-list tables landed. Allowed rather than
	76	+	/// worked around: the array is the point of the macro.
	77	+	#[allow(
	78	+	clippy::large_stack_arrays,
	79	+	reason = "sqlx::migrate! embeds the whole directory"
	80	+	)]
72	81		fn latest_migration_version() -> i64 {
73	82		sqlx::migrate!("./migrations")
74	83		.iter()
			@@ -186,6 +195,7 @@
186	195		.expect("connect to template database");
187	196
188	197		let t_migrate = std::time::Instant::now();
	198	+	#[allow(clippy::large_stack_arrays, reason = "sqlx::migrate! embeds the whole directory")]
189	199		sqlx::migrate!("./migrations")
190	200		.run(&tpl_pool)
191	201		.await