[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-08. 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.

[jasnell]

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

[clanky-the-clanker]

💬 Approved with comments — The change is correct and minimal. The one suggestion is about the enable date falling on a Sunday.

Findings: 1 suggestion

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

🔧 Fix with your agent

Paste the following into your coding agent to investigate and fix these issues.

Fix the following code review issues found in pull request #7798.

Before making changes, review each issue and present a brief summary table:
- For each finding, state whether you agree, disagree, or need clarification
- If you disagree (e.g., the fix would require disproportionate changes
  for minimal ROI, or the finding is factually incorrect), explain why
- If you need to clarify something before deciding, ask those questions
- Then share your plan for which issues to tackle and in what order

## SUGGESTION (1)

### [Code Quality] The new enable date 2026-11-08 is a Sunday, so it needed an exception in the weekday test. Consider a Tuesday–Thursday date such as 2026-11-10 and drop the exception, or keep the exception comment limited to dates that can't be changed.
- **File:** src/workerd/io/compatibility-date-test.c++:635

---

📋 Code Quality: 💬 1 suggestion

The change is correct. The new enable date is a Sunday and needed a weekday-test exception.

Recommendation: 💬 Optional Nits

• [SUGGESTION] The new enable date 2026-11-08 is a Sunday, so it needed an exception in the weekday test. Consider a Tuesday–Thursday date such as 2026-11-10 and drop the exception, or keep the exception comment limited to dates that can't be changed. (src/workerd/io/compatibility-date-test.c++:635)

View full review

The new enable date is a Sunday and needs a weekday-test exception (src/workerd/io/compatibility-date.capnp, src/workerd/io/compatibility-date-test.c++)

• The test "compatibility dates must be Tuesday, Wednesday, or Thursday" enforces a release-date convention. 2026-11-08 is a Sunday, so the PR adds enableRequestSignal to the exception list.
• The old comment limited that list to dates that were already deployed and couldn't be changed. The new comment, "Specific flags with compatibility dates outside the normal release weekdays", reads as open to any new entry.
• This date isn't deployed yet, so it could move to a Tuesday–Thursday date such as 2026-11-10. That would remove the need for the exception.
• If the date is fixed by the announcement, keep it. In that case, consider restoring the comment's wording that limits the list to dates that can't be changed.
• A weekend flip also leaves fewer engineers around if the new default causes regressions.

I checked how the default interacts with the rest of the code and found no other problems. worker-entrypoint.c++ reads getEnableRequestSignal(), so only dates on or after 2026-11-08 change. The request-signal wd-tests set their flags explicitly. The @all-compat-flags variant uses 2999-12-31, so it now enables the signal by default, and I found no test that depends on it being off.

---

_{Reviewed commit: 92ce48b1}

[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));
	}