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

Bytecode compiled during build is always discarded at runtime: SAM packaging writes 1980 timestamps, so timestamp-based .pyc never validate

オープン
  • 何か問題がありますか？
#924 コメント 1 件 リアクション 1 件 担当者 0 名 GitHub で見る

メンテナーはふだん 10 日以内に返信

@xujiantop-crypto がすでに取り組んでいます。

2026年9月16日 から。

  • #926 @xujiantop-crypto による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
64/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python
領域
build-system, performance

調査の方向性

Start with the python_uv workflow's compile_bytecode handling and trace where the builder invokes bytecode compilation; compare the resulting .pyc headers before and after the ZIP round trip described here. The fix is done when compiled artifacts use unchecked-hash invalidation and the existing build path no longer produces timestamp-based .pyc files that fail validation in the packaged artifact.

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

説明

Describe the bug

.pyc files produced during a build use timestamp-based invalidation by default: each one records
the source file's mtime and size, and CPython recompiles the module if either differs at import
time.

SAM CLI writes Lambda ZIPs with no timestamps at all, so every source file arrives in /var/task
dated 1980-01-01 and no timestamp-based .pyc can ever validate. The bytecode is shipped, read,
rejected, and recompiled on every cold start. Because /var/task is read-only, the recompiled
result cannot be cached either, so the cost is paid again by every execution environment.

This means any bytecode compilation added to a builder — see #839, and the compile_bytecode
field in the python_uv workflow — produces artifacts that are strictly worse than not compiling:
larger package, identical cold start.

Why the timestamps are zero

samcli/lib/package/utils.py, make_zip_with_permissions() constructs each entry as a bare
zipfile.ZipInfo(relative_path) and deliberately does not set date_time:

info = zipfile.ZipInfo(relative_path)
...
# ZIP date time can be set to the last time the zip content was modified using this logic.
# info.date_time = time.localtime()[0:6]

# If the date time above is added, the caching logic that compares ZIP files sha will break.
# Currently we skip executing sync flows for sam sync command when the logic ZIP hash is
# the same as the remote lambda ZIP hash. A timestamp will make the evaluation always false.
# However, without this field, contents of the zip file will have a last modified date 1980
# because python's zipfile.ZipInfo is set to: https://docs.python.org/3/library/zipfile.html.
zf.writestr(info, file_bytes, compress_type=compression_type)

Both make_zip and make_zip_with_lambda_permissions are functools.partial wrappers with
non-empty permission_mappers, so this branch always runs for Lambda artifacts.

The omission is intentional and load-bearing for sam sync hash comparison, so the fix belongs on
the builder side, not in the packaging code.

Steps to reproduce
import zipfile, io
buf = io.BytesIO()
with zipfile.ZipFile(buf, "w") as zf:
    info = zipfile.ZipInfo("mod.py")   # exactly what samcli does
    info.create_system = 3
    zf.writestr(info, b"x = 1")
with zipfile.ZipFile(buf) as zf:
    print(zf.getinfo("mod.py").date_time)

Observed: (1980, 1, 1, 0, 0, 0)

End to end, against a real build artifact containing 718 uv-compiled .pyc (produced with
UV_COMPILE_BYTECODE=1 sam build), comparing each .pyc header's recorded source mtime and size
against the source file on disk, before and after a ZIP round trip:

as built (on disk)           valid=718  STALE=0
after zip round-trip         valid=0    STALE=718

Note that ZIP timestamps could not fix this even if they were written: the format stores DOS
date/time at 2-second resolution, while .pyc records the source mtime as whole seconds, so
roughly half of all files would still mismatch.

Expected result

Builders that compile bytecode should use hash-based, unchecked invalidation, which records a hash
of the source instead of its mtime and does not consult the source file at import time:

python -m compileall --invalidation-mode unchecked-hash <artifact dir>

or, for uv, whatever equivalent it grows. Verified on the same artifact:

compileall -f --invalidation-mode unchecked-hash, then zip round-trip:
  .py files:            977
  unchecked-hash .pyc:  977
  timestamp .pyc:         0
  zip size:            17.2 MB (unchanged)

-f matters if uv has already compiled part of the tree: plain compileall skips any file that
already has a .pyc, so it leaves uv's timestamp-based ones in place and fixes only the rest.

Why this is worth doing

On a FastAPI function with 977 .py files in the artifact, measured with the same module graph
(899 modules) and the only difference being whether __pycache__ was present:

with .pyc:      293 / 297 / 298 / 299 / 302 ms
without .pyc:   822 / 878 / 887 ms

Compilation is roughly 65% of import time. On the deployed function the import graph accounts for
2081 ms of a 2145 ms init, so shipping valid bytecode is worth several hundred milliseconds per
cold start, on a code path where SnapStart and provisioned concurrency are the only alternatives
and both cost money.

Versions
  • aws-lambda-builders 1.67.0
  • SAM CLI 1.166.2
  • Host Python 3.14.3, target runtime python3.14, architecture arm64
主要言語
Python
スター
381
フォーク
161
平均マージ
9日 8時間
マージ済み PR（30日）
2

環境構築

はじめの一歩

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

aws/aws-lambda-builders のほかの issue

aws/aws-lambda-builders の issue をすべて見る

似ている issue

Python の issue をもっと見る

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

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