Skip to content

fix(core): fix race condition in resource()#59851

Closed
alxhub wants to merge 1 commit intoangular:mainfrom
alxhub:fix-resource-race
Closed

fix(core): fix race condition in resource()#59851
alxhub wants to merge 1 commit intoangular:mainfrom
alxhub:fix-resource-race

Conversation

@alxhub
Copy link
Copy Markdown
Member

@alxhub alxhub commented Feb 4, 2025

The refactoring of resource() to use linkedSignal() introduced the potential for a race condition where resources would get stuck and not update in response to a request change. This occurred under a specific condition:

  1. The request changes while the resource is still in loading state
  2. The resource resolves the previous load before its effect() reacts to the request change.

In practice, the window for this race is small, because the request change in (1) will schedule the effect in (2) immediately. However, it's easier to trigger this sequencing in tests, especially when one resource depends on the output of another.

To fix the race condition, the resource impl is refactored to track the request in its state, and ignore resolved values or streams for stale requests. This refactoring actually makes the resource code simpler and easier to follow as well.

Fixes #59842

@angular-robot angular-robot bot added the area: core Issues related to the framework runtime label Feb 4, 2025
@ngbot ngbot bot added this to the Backlog milestone Feb 4, 2025
The refactoring of `resource()` to use `linkedSignal()` introduced the
potential for a race condition where resources would get stuck and not update
in response to a request change. This occurred under a specific condition:

1. The request changes while the resource is still in loading state
2. The resource resolves the previous load before its `effect()` reacts to the
   request change.

In practice, the window for this race is small, because the request change in
(1) will schedule the effect in (2) immediately. However, it's easier to
trigger this sequencing in tests, especially when one resource depends on the
output of another.

To fix the race condition, the resource impl is refactored to track the request
in its state, and ignore resolved values or streams for stale requests. This
refactoring actually makes the resource code simpler and easier to follow as
well.

Fixes angular#59842
@alxhub alxhub force-pushed the fix-resource-race branch from f56af81 to 3ea10b4 Compare February 5, 2025 00:02
@alxhub alxhub added the target: patch This PR is targeted for the next patch release label Feb 5, 2025
Copy link
Copy Markdown
Member

@pkozlowski-opensource pkozlowski-opensource left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Reviewed-for: public-api
Reviewed-for: fw-core

@pullapprove pullapprove bot requested a review from thePunderWoman February 5, 2025 15:29
Copy link
Copy Markdown
Contributor

@thePunderWoman thePunderWoman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reviewed-for: public-api

@alxhub alxhub added action: merge The PR is ready for merge by the caretaker target: minor This PR is targeted for the next minor release and removed target: patch This PR is targeted for the next patch release labels Feb 5, 2025
@alxhub
Copy link
Copy Markdown
Member Author

alxhub commented Feb 5, 2025

This PR was merged into the repository by commit b592b1b.

The changes were merged into the following branches: main

@alxhub alxhub closed this in b592b1b Feb 5, 2025
PrajaktaB27 pushed a commit to PrajaktaB27/angular that referenced this pull request Feb 7, 2025
The refactoring of `resource()` to use `linkedSignal()` introduced the
potential for a race condition where resources would get stuck and not update
in response to a request change. This occurred under a specific condition:

1. The request changes while the resource is still in loading state
2. The resource resolves the previous load before its `effect()` reacts to the
   request change.

In practice, the window for this race is small, because the request change in
(1) will schedule the effect in (2) immediately. However, it's easier to
trigger this sequencing in tests, especially when one resource depends on the
output of another.

To fix the race condition, the resource impl is refactored to track the request
in its state, and ignore resolved values or streams for stale requests. This
refactoring actually makes the resource code simpler and easier to follow as
well.

Fixes angular#59842

PR Close angular#59851
@angular-automatic-lock-bot
Copy link
Copy Markdown

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Mar 8, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

action: merge The PR is ready for merge by the caretaker area: core Issues related to the framework runtime target: minor This PR is targeted for the next minor release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Race condition in resource()

4 participants