Strange behavior of require-atomic-updates #14695
Comments
eslint-github-bot
bot
added
the
triage
|
I didn't see this discussed in #11899, and I think it may be a separate issue, so that's why I brought it up separately. |
|
Strange indeed. I’m able to repro this in the ESLint demo. This feels like it might be a side effect of #13915. The code reads the variable, but the assign is still stale. It might be possible to fix this and #11899 in the same commit if we were to tweak how this rule works and start looking at the right hand side of the assign to see if it depends on anything that was read from the target of the assign before the await. |
btmills
added
bug
I think this is the same as #11899. A property of
I think this is correct behavior for this rule - |
|
I see what you mean about how it is read after the await. I think the rule is behaving correctly as defined, but I think the definition of the rule is a bit off. #11899 is about false positives. Here I am calling attention to the false negation of the error whether it's a false positive or not; that is, the fact that adding the line /* eslint require-atomic-updates: "error" */
let obj = { value: 1 };
const changeValue = async () => {
obj.value += 2;
return 7;
}
// Correctly reported buggy version. Value should be
// 1 + 2 + 7 = 10, but instead it is 1 + 7 = 8
async () => {
const value = obj.value; // value = 1
const result = await changeValue(); // result = 7, but now obj.value = 3
obj.value = value + result; // obj.value assigned to 8, not 10
};
// False negative version. Yes, obj is read before the final assignment,
// but the bug stil exists and in unreported now.
async () => {
const value = obj.value;
const result = await changeValue();
obj;
obj.value = value + result;
};Same code in Demo. |
I think this behavior makes sense given how the rule treats assignments to properties, because the logic isn't based on property names. The rule only checks if the object was used before /* eslint require-atomic-updates: error */
let obj = { value: 1 };
async () => {
obj;
const result = await something;
obj.value = result; // error, `obj.value` might be assigned based on an outdated state of `obj`
};If any access to the object before |
|
If that's the proper behavior, that's fine. This issue points out that the way one might expect the rule to work is different from the actual implementation of the rule. |
|
Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update. |
|
@github-actions The |
eslint-github-bot
bot
added
the
archived due to age
Environment
Parser
reactplugin and@typescript-eslintpluginFull configuration:
Configuration
What did you do?
What did you expect to happen?
Look at the
test1function. I put a uselessawaitinside, then I got an error on the linething.name = name;. I don't see how the line in question is a race condition. Yes, there is anawaitbefore it, but that does nothing. If this is just marked improperly as a "potential" race condition, that would be just fine with me and no need to report a bug.However, take a look at the
test2function. Now I add another useless line,const _ = thing;. This does nothing, yet it causes therequire-atomic-updateserror on the following line to go away. I'm don't think this should be the expected behavior here.What actually happened?
The text was updated successfully, but these errors were encountered: