codegen: floor descriptor_pool()'s scaled element-memory bound at the default (#360)

Fixes #336.

## The problem

Generated `descriptor_pool()` scales its decode bound to
`FILE_DESCRIPTOR_SET_BYTES.len() * 64`. For descriptor sets built mostly
from short single-character type names, the real per-byte amplification
runs above 64x — up to 352x for an empty `FileDescriptorProto` element,
which is the tightest possible case for `descriptor.proto` on 64-bit
targets. So the scaled bound can come out *smaller* than the flat 32 MiB
`DEFAULT_ELEMENT_MEMORY_LIMIT` it replaced. The issue's own trigger
shape
(50 outer messages × 26 one-character nested messages) reproduces this:
it's well under 1 KiB, needs ~71.5x to decode, and the 64x-scaled bound
rejects it even though the pre-0.9.1 flat default accepted it fine.

(Small correction while reproducing: the issue's own repro table reports
68-69x for this shape; the actual measured ratio is 71.5x. Traced to a
`format!("{:0width$}", i, width=1)` name-padding bug in whatever
generated
that table, not a discrepancy in the shape itself — doesn't change the
conclusion, just flagging it since the corrected number is what this
PR's
test locks in.)

## The fix

```rust
FILE_DESCRIPTOR_SET_BYTES
    .len()
    .saturating_mul(64)
    .max(::buffa::DEFAULT_ELEMENT_MEMORY_LIMIT)
```

Floors the scaled bound at the old default. This makes the emitted bound
provably monotonic relative to what it replaced — it can only loosen,
never tighten — which is the specific property missing today.

This intentionally does **not** try to resolve whether 64x is the right
multiplier in general. It isn't a proven bound; 352x is, for
`descriptor.proto` on 64-bit targets, today (32-bit wasn't measured and
would need re-deriving — `size_of` scales with pointer width). Landing
the
floor now doesn't foreclose adopting 352, or an exact/trusted-input
budget, later; all of those remain `.max()`-compatible with this floor
or
supersede it cleanly.

Worth noting: @iainmcgin's own PR description for #332 — the commit that
introduced this bound — already named the real fix and deliberately
deferred it:

> the durable fix is a bound expressed as a multiple of the encoded
input
> length, which would need no per-call-site exemption and would
> self-tune... That is an API change to `DecodeOptions` touching the
> untrusted-input posture, so it does not belong in a regression fix.

This PR doesn't attempt that larger API change either — it's scoped the
same way #332 was, to the narrow regression this issue reports. Picking
a
tighter proven multiplier (or the exact-budget/trusted-input
alternatives)
is a separate, larger decision for whoever owns that tradeoff.

## What else this touches

`buffa-types/src/generated/google.protobuf.mod.rs` is regenerated via
`task gen-wkt-types` so the bundled well-known-types pool picks up the
same fix — confirmed the regen is idempotent (ran it twice, diffed the
output directly, byte-identical).

## Testing

New `buffa-descriptor/tests/issue_336_floor.rs`:
- `old_formula_rejects_the_trigger_shape` — documents the bug on the
  issue's own trigger shape.
- `floored_formula_accepts_the_trigger_shape` — proves the fix on that
  same shape, and that it's the floor (not the scaled term) doing the
  work.
- `floor_is_monotonic_never_below_default` — sweeps several input
lengths
  proving the floor never dips below the default, and checks the
  crossover point (where scaling starts to dominate the floor) lands at
  exactly 512 KiB, matching the issue's own math.

Strengthened the existing `reflect_pool_module_emits_well_formed_tokens`
codegen test to assert the emitted tokens reference
`DEFAULT_ELEMENT_MEMORY_LIMIT` — it previously only checked that the
module parses and mentions the bytes constant, so it wouldn't have
caught
a future edit silently dropping the floor.

`cargo test --workspace`, `cargo fmt --all --check`, and `cargo clippy
--workspace --all-targets -- -D warnings` all pass.

---------

Co-authored-by: Iain McGinniss <309153+iainmcgin@users.noreply.github.com>

Author: yanmo42

.changes/unreleased/fixed-20260728-103943.yaml

@@ -0,0 +1,3 @@
+kind: Fixed
+body: '**Generated `descriptor_pool()` no longer rejects small schemas built from short type names** (#336, #360). The scaled element-memory bound (`len * 64`) could come out tighter than the untrusted-input default it replaced: descriptor sets whose bulk is one-character type names amplify past 64x (the issue''s shape measures ~71.5x on 64-bit), so a few-kilobyte schema was rejected even though the flat 32 MiB default before 0.9.1 accepted it. The bound is now floored at `DEFAULT_ELEMENT_MEMORY_LIMIT`, so it can only ever be looser than that default, never tighter.'
+time: 2026-07-28T10:39:43.538612562-04:00

buffa-codegen/src/reflect.rs

@@ -209,6 +209,10 @@ pub(crate) fn reflect_pool_module(fds_bytes: &[u8]) -> TokenStream {
             /// finite, so corrupt embedded bytes still fail rather than
             /// exhausting memory.
             ///
+            /// The scaled bound is floored at
+            /// [`DEFAULT_ELEMENT_MEMORY_LIMIT`](::buffa::DEFAULT_ELEMENT_MEMORY_LIMIT),
+            /// so it is never tighter than the untrusted-input default.
+            ///
             /// # Panics
             ///
             /// Panics on first access if the embedded bytes are malformed —
@@ -222,7 +226,10 @@ pub(crate) fn reflect_pool_module(fds_bytes: &[u8]) -> TokenStream {
                 POOL.get_or_init(|| {
                     let options = ::buffa::DecodeOptions::new()
                         .with_element_memory_limit(
-                            FILE_DESCRIPTOR_SET_BYTES.len().saturating_mul(64),
+                            FILE_DESCRIPTOR_SET_BYTES
+                                .len()
+                                .saturating_mul(64)
+                                .max(::buffa::DEFAULT_ELEMENT_MEMORY_LIMIT),
                         );
                     ::buffa::alloc::sync::Arc::new(
                         ::buffa_descriptor::DescriptorPool::decode_with_options(
@@ -488,6 +495,16 @@ mod tests {
         let parsed = syn::parse2::<syn::ItemMod>(tokens.clone());
         assert!(parsed.is_ok(), "generated module must parse: {tokens}");
         assert!(tokens.to_string().contains("FILE_DESCRIPTOR_SET_BYTES"));
+        // #336: the emitted bound must floor at the untrusted-input default,
+        // not just scale with length. Match the code form with spacing
+        // stripped — the doc comment above it names the same constant, so a
+        // bare substring check would pass on the doc text alone.
+        let code = tokens.to_string().replace(' ', "");
+        assert!(
+            code.contains(".saturating_mul(64).max(::buffa::DEFAULT_ELEMENT_MEMORY_LIMIT)"),
+            "descriptor_pool() must floor its scaled bound at \
+             DEFAULT_ELEMENT_MEMORY_LIMIT (#336): {tokens}"
+        );
     }
 
     #[test]

buffa-descriptor/tests/pool_decode_limits.rs

@@ -204,3 +204,76 @@ fn nesting_deeper_than_the_name_cap_is_refused() {
         Err(PoolError::NameTooLong { .. })
     ));
 }
+
+/// The issue's trigger shape for #336: 50 messages each nesting 26 empty
+/// one-character messages. Every nested element costs ~5 wire bytes and
+/// materializes a full `DescriptorProto`, so the element-to-encoded ratio
+/// (~71.5x on 64-bit) exceeds the 64x multiplier generated
+/// `descriptor_pool()` scales its bound by.
+fn short_name_descriptor_set() -> Vec<u8> {
+    const NAMES: &[u8] = b"abcdefghijklmnopqrstuvwxyz";
+    let name = |i: usize| Some((NAMES[i % NAMES.len()] as char).to_string());
+    let mut file = FileDescriptorProto {
+        name: Some("a".to_string()),
+        ..Default::default()
+    };
+    for i in 0..50 {
+        file.message_type.push(DescriptorProto {
+            name: name(i),
+            nested_type: (0..26)
+                .map(|j| DescriptorProto {
+                    name: name(j),
+                    ..Default::default()
+                })
+                .collect(),
+            ..Default::default()
+        });
+    }
+    FileDescriptorSet {
+        file: vec![file],
+        ..Default::default()
+    }
+    .encode_to_vec()
+}
+
+fn decodes_under(bytes: &[u8], limit: usize) -> bool {
+    DecodeOptions::new()
+        .with_element_memory_limit(limit)
+        .decode_from_slice::<FileDescriptorSet>(bytes)
+        .is_ok()
+}
+
+/// Why generated `descriptor_pool()` floors its scaled bound (#336): the
+/// element charge is `size_of::<DescriptorProto>()` per nested message, so a
+/// schema made of short names amplifies past 64x and the bare `len * 64`
+/// bound rejects what the flat default accepted.
+///
+/// The ratio scales with pointer width (descriptor types are mostly `Vec`
+/// and `Option<String>` fields), so on 32-bit targets the same shape lands
+/// under 64x and this no longer demonstrates the bug.
+#[cfg(target_pointer_width = "64")]
+#[test]
+fn scaled_bound_alone_rejects_short_name_schemas() {
+    let bytes = short_name_descriptor_set();
+    assert!(
+        !decodes_under(&bytes, bytes.len().saturating_mul(64)),
+        "expected the un-floored 64x bound to reject this shape; if it now \
+         decodes, the shape is no longer a #336 trigger and needs replacing"
+    );
+}
+
+/// With the floor, the generated bound can never be tighter than the
+/// untrusted-input default, so anything the default accepts still decodes.
+#[test]
+fn floored_bound_accepts_what_the_default_accepts() {
+    let bytes = short_name_descriptor_set();
+    let floored = bytes
+        .len()
+        .saturating_mul(64)
+        .max(buffa::DEFAULT_ELEMENT_MEMORY_LIMIT);
+    assert!(decodes_under(&bytes, floored), "{} bytes", bytes.len());
+    // The floor is what binds here; the scaled term only takes over past
+    // 512 KiB of embedded descriptor bytes.
+    assert_eq!(floored, buffa::DEFAULT_ELEMENT_MEMORY_LIMIT);
+    assert_eq!(buffa::DEFAULT_ELEMENT_MEMORY_LIMIT / 64, 512 * 1024);
+}