max / makenotwork

s3-storage: pin the multipart limits to the bytes S3 documents Every limit is written as an arithmetic expression, and mutation found that nothing asserted the result: `5 * 1024 * 1024 * 1024` could become `5 + 1024 + 1024 + 1024` and the whole suite still passed (infra 1498fe2a). The planner's own tests cannot catch it, since a plan built from a wrong ceiling is still self-consistent; only S3 would object, at complete time.

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

Author: Max Johnson <me@maxj.phd> · 2026-08-27 01:55 UTC

Signed with PGP, not checked

Commit: d1d2c59afc4892de0ef9a6e7cdb66651c431030b

Parent: 7036584

1 file changed, +17 insertions, -0 deletions

M shared/s3-storage/src/lib.rs +17

			@@ -1412,6 +1412,23 @@
1412	1412		oracle::check_plan(25 * MIB, MULTIPART_MAX_PART_SIZE as usize + 1);
1413	1413		}
1414	1414
	1415	+	#[test]
	1416	+	fn the_limits_are_the_numbers_the_s3_contract_states() {
	1417	+	// Every one of these is written as an arithmetic expression, and an
	1418	+	// expression nothing asserts is a number nothing pins: mutation found
	1419	+	// that `5 * 1024 * 1024 * 1024` could become `5 + 1024 + 1024 + 1024`
	1420	+	// and no test noticed (infra `1498fe2a`). The plans built from them
	1421	+	// would still be self-consistent, which is exactly why the planner's
	1422	+	// own tests cannot catch it. Stated here in bytes, from the S3 API
	1423	+	// contract.
	1424	+	assert_eq!(MULTIPART_MIN_PART_SIZE, 5_242_880, "5 MiB");
	1425	+	assert_eq!(MULTIPART_MAX_PARTS, 10_000);
	1426	+	assert_eq!(MULTIPART_MAX_PART_SIZE, 5_368_709_120, "5 GiB");
	1427	+	assert_eq!(MULTIPART_MAX_OBJECT_SIZE, 5_497_558_138_880, "5 TiB");
	1428	+	assert_eq!(MULTIPART_DEFAULT_PART_SIZE, 16_777_216, "16 MiB");
	1429	+	assert_eq!(MAX_PRESIGN_EXPIRY_SECS, 604_800, "7 days, SigV4's maximum");
	1430	+	}
	1431	+
1415	1432		#[test]
1416	1433		#[should_panic(expected = "disagrees with div_ceil")]
1417	1434		fn oracle_catches_a_part_count_the_client_would_reject() {