Build cache ignores maxResponseBytes, potentially reusing an outdated response limit

Build cache ignores maxResponseBytes, potentially reusing an outdated response limit

Summary

buildAppRelease() embeds config.maxResponseBytes in the generated application wrapper, but does not include this setting in the build-cache key.

Changing the response limit while keeping application source unchanged therefore produces the same cache key. If a cached artifact exists, the build can reuse the wrapper containing the previous limit.

Code evidence

In packages/dynamic-apps-core/src/build.ts:

• canonicalDeploymentHash() receives the source files, entrypoint, build flag, and packaging identity.
• The packaging identity does not include config.maxResponseBytes.
• artifactCache.get(buildId) can return an existing artifact before a new wrapper is generated.
• When a build does run, directRunnerSource() receives config.maxResponseBytes.

In packages/dynamic-apps-core/src/runtime.ts, directRunnerSource() embeds that value into the response-size checks.

Sources:

• https://github.com/rivet-dev/dynamic-apps/blob/efcee03d7dbe388ffaf0231c1beb9316b84f7447/packages/dynamic-apps-core/src/build.ts
• https://github.com/rivet-dev/dynamic-apps/blob/efcee03d7dbe388ffaf0231c1beb9316b84f7447/packages/dynamic-apps-core/src/runtime.ts

Reproduction scenario to verify

1. Build an application with config.maxResponseBytes set to 1024, using an artifact cache.
2. Keep the source files and other build inputs unchanged.
3. Build it again with config.maxResponseBytes set to 2048, using the same cache.
4. Compare the cache keys and check whether the second build reuses the first artifact.
5. Serve a response containing 1536 bytes.

Expected behavior

Changing the response limit should produce a different cache key and a new artifact containing the updated limit.

The second deployment should allow the 1536-byte response.

Equivalent effective limits, including the default and its explicitly specified value, should retain the same cache key.

Suspected behavior

Both configurations produce the same cache key. The second build can return the cached artifact containing the 1024-byte limit, causing the response to remain rejected.

The reverse change could also retain an older, larger limit after the configured limit is reduced.

Suggested fix

Include the effective maxResponseBytes value in the build-cache identity.

Add regression coverage verifying that:

• Different response limits produce different cache keys.
• Repeated builds with the same effective limit retain the same key.
• An omitted limit and the explicit default produce the same key.

Start in packages/dynamic-apps-core/src/build.ts by tracing canonicalDeploymentHash(), the packaging identity, and artifactCache.get(buildId). Then read directRunnerSource() in packages/dynamic-apps-core/src/runtime.ts and add regression coverage for changed, repeated, and default-equivalent maxResponseBytes values. Done means effective limits produce the expected cache-key behavior and a changed limit is used by a new artifact.