[irvinebroque]

Incoming requests currently require enable_request_signal to report client disconnections through Request.signal. Make this behavior the default for compatibility dates on or after 2026-11-17. Earlier dates retain their current behavior, disable_request_signal remains an opt-out, and request_signal_passthrough is unchanged.

The companion docs PR includes an October 17 advance announcement, an example, and a link to the May 2025 announcement.

Regression coverage checks the day before and day of the November 17 boundary, early opt-in, and the disable_request_signal opt-out.

Validation: the focused C++ November 16/17 boundary test passed against the production compatibility-date library using a temporary lightweight harness, including early opt-in and opt-out. Schema generation, date consistency, edited-line formatting preservation, and git diff --check passed. Full Bazel and server integration suites were not completed locally.

[jasnell]

The default on date might need to be pushed out another week or two

[clanky-the-clanker]

This pull request's reviews are posted as pull request reviews: see the review of f56b70b0.

[ask-bonk]

Since last review: 0 resolved, 1 still open, 0 new.

No changes since the prior review; the compatibility-date default remains untested at its boundary.

---

_{Reviewed commit: 92ce48b1 · github run}

[ask-bonk]

[WARNING] The updated test only exempts this field from the weekday check; it never compiles a date on either side of 2026-11-08. Deleting or changing this annotation, or breaking the disable_request_signal override, would therefore pass the suite while removing the announced default. Add a boundary assertion to KJ_TEST("encode to full flag list") in compatibility-date-test.c++:

Suggested change

	$compatEnableDate("2026-11-08");
	{
	constexpr auto flag = "enable_request_signal"_kj;
	KJ_EXPECT(!contains(
	decompileCompatibilityFlags(compileOwnFeatureFlags("2026-11-07", {}).get()), flag));
	KJ_EXPECT(contains(
	decompileCompatibilityFlags(compileOwnFeatureFlags("2026-11-08", {}).get()), flag));
	KJ_EXPECT(!contains(decompileCompatibilityFlags(compileOwnFeatureFlags(
	"2026-11-08", {"disable_request_signal"_kj})
	.get()),
	flag));
	}

[clanky-the-clanker]

Superseded by the review of 86a21539.

This review, of f56b70b0

💬 Approved with comments — The change is correct and minimal. The only open point is a suggestion about the Sunday enable date and the weekday-test exception.

Findings: 1 suggestion

_{The decision is advisory: this review is a comment and never approves, blocks or requests changes on the pull request.}

---

📋 Code Quality: 💬 1 suggestion

Correct, minimal change; one suggestion about the Sunday enable date.

Recommendation: 💬 Optional Nits

• [SUGGESTION] The enable date 2026-11-08 is a Sunday, so it needs a new weekday-test exception. A Tuesday–Thursday date would avoid that, and an existing review already says the date may need to move. If the Sunday date is fixed, restore comment wording that limits the exception list to dates that can't be changed. (src/workerd/io/compatibility-date-test.c++:635)

View full review

Sunday enable date and weekday-test exception

• The test "compatibility dates must be Tuesday, Wednesday, or Thursday" enforces the release-weekday convention. 2026-11-08 is a Sunday, so enableRequestSignal was added to allowedFlagExceptions.
• The previous comment limited the exceptions to dates that were already deployed and couldn't be changed. The new wording, "Specific flags with compatibility dates outside the normal release weekdays", reads as open to any new entry. This date hasn't shipped yet.
• An existing approving review says the date may need to move out another week or two. If it moves to a Tuesday–Thursday date, such as 2026-11-10 or later, the exception entry and the comment edit can both be dropped.
• If the public announcement fixes the Sunday date, keep the exception. In that case, restore wording that limits the list to dates that can't be changed.

---

_{Reviewed commit: f56b70b0}

[clanky-the-clanker]

Superseded by the review of d2bd9877.

This review, of 86a21539

✅ Approved — The one-line enable-date change is correct and minimal. 2026-11-12 is a Thursday, opt-in and opt-out behaviour is preserved, and no findings were raised.

_{The decision is advisory: this review is a comment and never approves, blocks or requests changes on the pull request.}

---

✅ All checks passed

📋 Code Quality: ✅ LGTM

The enable date is added to enableRequestSignal and the stale comment is removed. The weekday test is unaffected because 2026-11-12 is a Thursday. The existing request-signal tests set their flags explicitly, so they do not depend on the default.

---

_{Reviewed commit: 86a21539}

[clanky-the-clanker]

Superseded by the review of 3adbfe0d.

This review, of d2bd9877

✅ Approved — The date change is minimal and correct, and the new test covers the boundary, early opt-in and opt-out. No issues found.

_{The decision is advisory: this review is a comment and never approves, blocks or requests changes on the pull request.}

---

✅ All checks passed

📋 Code Quality: ✅ LGTM

The new test checks getEnableRequestSignal() on each side of the 2026-11-12 boundary and with each override flag. It follows the existing compile-helper pattern in compatibility-date-test.c++. No issues found.

---

📝 Documentation: ✅ LGTM

The comment saying the flag is experimental and has no default enable date has been removed, so the schema comment now matches the code. User-facing docs are handled in a separate docs pull request.

---

_{Reviewed commit: d2bd9877}

[clanky-the-clanker]

Superseded by the review of b5a62793.

This review, of 3adbfe0d

✅ Approved — The enable-date change is small and correct, and the new test covers the boundary, early opt-in and the opt-out. No issues found.

_{The decision is advisory: this review is a comment and never approves, blocks or requests changes on the pull request.}

---

✅ All checks passed

📋 Code Quality: ✅ LGTM

The $compatEnableDate("2026-11-17") annotation is correct, and the date is a weekday. The new test checks the day before and the day of the boundary, early opt-in, and the disable_request_signal opt-out, using the existing compile-helper pattern. Runtime use in worker-entrypoint.c++ reads getEnableRequestSignal() and needs no change.

---

📝 Documentation: ✅ LGTM

The schema comment now matches the code, since the note about the flag having no default enable date is gone. User-facing documentation is in the companion docs pull request.

---

_{Reviewed commit: 3adbfe0d}

[codecov-commenter]

Codecov Report

❌ Patch coverage is 73.68421% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.34%. Comparing base (69bea9b) to head (b5a6279).

Files with missing lines	Patch %	Lines
src/workerd/io/compatibility-date-test.c++	73.68%	0 Missing and 5 partials ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7798   +/-   ##
=======================================
  Coverage   68.33%   68.34%           
=======================================
  Files         726      726           
  Lines      189924   189943   +19     
  Branches    29738    29744    +6     
=======================================
+ Hits       129792   129808   +16     
- Misses      42705    42706    +1     
- Partials    17427    17429    +2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[irvinebroque]

@jasnell I am merging docs change that announces Nov 17th, so that this can land

[clanky-the-clanker]

✅ Approved — This is a small, correct change to the enable date, with tests for the boundary, early opt-in and opt-out. No issues found.

_{The decision is advisory: this review is a comment and never approves, blocks or requests changes on the pull request.}

---

✅ All checks passed

📋 Code Quality: ✅ LGTM

• src/workerd/io/compatibility-date.capnp: The $compatEnableDate("2026-11-17") annotation is correct.
• src/workerd/io/compatibility-date-test.c++: The new test checks the day before and the day of the boundary, early opt-in, and the disable_request_signal opt-out.
• The runtime code in worker-entrypoint.c++ only reads the flag, so it needs no change. The existing request-signal .wd-test files set their flags explicitly, so the new default does not affect them.

---

📝 Documentation: ✅ LGTM

The schema comment matches the new default. User-facing documentation is in the companion docs pull request.

---

_{Reviewed commit: b5a62793}