Skip to content

Fix specialization double-start race - #841

Open
Swapnil Nagar (swapnil-nagar) wants to merge 1 commit into
v3.xfrom
swapnil-nagar-fix-specialization-race
Open

Fix specialization double-start race#841
Swapnil Nagar (swapnil-nagar) wants to merge 1 commit into
v3.xfrom
swapnil-nagar-fix-specialization-race

Conversation

@swapnil-nagar

Copy link
Copy Markdown
Contributor

A specialization race can send WorkerInitRequest and FunctionEnvironmentReloadRequest for the same real app. Resetting app state before the second startup loses v4 registrations, while Node's module cache prevents their side effects from running again, leaving the worker on the default v3 model with no loadable functions.

This change preserves the initialized AppContext when both requests target the same directory while still applying the specialized environment and working directory. Normal placeholder specialization continues to reset and start the real app when its directory differs. Entry-point globbing also excludes node_modules so broad main patterns cannot load dependencies as application entry points.

Tests cover v4 model and function-registration preservation across the duplicate lifecycle sequence, normal placeholder specialization, and node_modules glob exclusion.

Fixes #838

Preserve initialized app state when worker init and environment reload target the same directory, and exclude node_modules from entry-point globs.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: eff15798-612c-4121-a6d4-ec5e093bff1f
@swapnil-nagar
Swapnil Nagar (swapnil-nagar) requested a review from a team as a code owner August 21, 2026 22:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Specialization race: double startApp() with stale require cache leaves worker on default v3 model with all functions unloadable

1 participant