Update folly hash for 11.7 release

[anand1976]

Summary

• Update folly.mk FOLLY_COMMIT_HASH to d1f69a7974fc

This is folly's main at release-cut time. Review and merge to take the bump, or close to skip folly for this release.

Part of 11.7 release workflow.

[github-actions]

✅ clang-tidy: No findings on changed lines

Completed in 0.0s.

[github-actions]

✅ Claude Code Review

Auto-triggered after CI passed — reviewing commit be3ee98

---

Summary

Trivial dependency bump: updates FOLLY_COMMIT_HASH in folly.mk to a new folly main commit (d1f69a7974fc) for the 11.7 release. The change is a single-line hash substitution with no logic, API, or behavioral modifications.

No high-severity findings.

Full review (click to expand)

Findings

🔴 HIGH

None.

🟡 MEDIUM

None.

🟢 LOW / NIT

L1. Post-checkout patches may need updating — folly.mk:140-141

• Issue: The checkout_folly target applies two source patches to folly after checkout (missing <cstring> include in Exception.h, and a const mismatch in Subprocess.cpp). A new folly commit may have already fixed these issues (making the patches no-ops) or changed the affected lines (making the patches fail silently or incorrectly).
• Suggested fix: After merging, verify the checkout_folly and build_folly targets succeed in CI. If either patch fails to match, remove or update it.

Cross-Component Analysis

The FOLLY_COMMIT_HASH variable is consumed only by the checkout_folly make target (line 138: git reset --hard $(FOLLY_COMMIT_HASH)). No other build system files (CMakeLists.txt, BUCK, src.mk) reference this variable. The change has no impact on the non-folly build path, which is the default.

Context	Affected?	Notes
USE_FOLLY=1 build	Yes	Will checkout and build the new folly commit
USE_FOLLY_LITE=1 build	Indirectly	Uses third-party/folly source checked out at this hash
Default build (no folly)	No	FOLLY_COMMIT_HASH is defined but never used
BUCK / CMake builds	No	Variable is only in folly.mk

Positive Observations

• The hash is a valid 40-character lowercase hex SHA-1, consistent with the expected format.
• The PR description clearly states this is part of the 11.7 release workflow and provides context for the bump.
• Pinning to a specific commit (rather than tracking main) is the correct approach for CI stability.

---

ℹ️ About this response

Generated by Claude Code.
Review methodology: claude_md/code_review.md

Limitations:

• Claude may miss context from files not in the diff
• Large PRs may be truncated
• Always apply human judgment to AI suggestions

Commands:

• /claude-review [context] — Request a code review
• /claude-query <question> — Ask about the PR or codebase