Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Build cache ignores maxResponseBytes, potentially reusing an outdated response limit

オープン
#297 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

@Utkarshpandey0001 がすでに取り組んでいます。

2026年9月19日 から。

  • #298 @Utkarshpandey0001 による — オープン

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
78/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
build-system

調査の方向性

packages/dynamic-apps-core/src/build.ts から始めて、canonicalDeploymentHash()、パッケージングの識別情報、artifactCache.get(buildId) を追跡します。次に packages/dynamic-apps-core/src/runtime.ts の directRunnerSource() を読み、変更された、繰り返された、デフォルトと同等の maxResponseBytes 値に対するリグレッションカバレッジを追加します。実効的な制限によって期待されるキャッシュキーの動作が得られ、変更された制限が新しいアーティファクトで使用されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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:

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.
主要言語
TypeScript
スター
1k
フォーク
54
PR マージ指標
30日以内にマージされた PR はありません

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

rivet-dev/dynamic-apps のほかの issue

rivet-dev/dynamic-apps の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。