Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUGFIX: Fix race-condition when initializing I18n Service #3188

Conversation

christianharrington
Copy link
Contributor

We noticed in our error logs that we had quite a few errors being thrown from here:

Call to a member function findBestMatchingLocale() on bool

My best guess is that this is due to a race-condition when the service is called for the first time on a host by multiple requests simultaneously.

In general, the pattern of first checking if some value is in the cache, and then reading the value out afterwards without checking it is never safe, as a different process/thread could have removed it.

The safe way is to read the value out once, and verify that it is set correctly (e.g. it should not === false).

I think there's a few other places that follow the same unsafe pattern, but I suggest that they are addresses separately from this PR.

I haven't added any tests for this case, but please let me know if you have any ideas of how to test this.

Checklist

  • Code follows the PSR-2 coding style
  • Tests have been created, run and adjusted as needed
  • The PR is created against the lowest maintained branch
  • Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
  • Reviewer - The first section explains the change briefly for change-logs
  • Reviewer - Breaking Changes are marked wit !!! and have upgrade-instructions

The previous implementation was an example of a check-then-act
race-condition: There is no guarantee that the cached value still exists
when it is subsequently read out.

This would cause errors later when `$this->localCollection` could
suddenly have the value `false`.
@mhsdesign mhsdesign force-pushed the bugfix/cached-collection-race-condition branch from b82054f to 6f9716e Compare February 11, 2024 19:01
@mhsdesign mhsdesign changed the base branch from 7.3 to 8.3 February 11, 2024 19:01
@github-actions github-actions bot added 8.3 and removed 7.3 labels Feb 11, 2024
@christianharrington
Copy link
Contributor Author

@kitsunet Any chance of getting this merged? Anything I can help with?

@markusguenther markusguenther merged commit b8dbee8 into neos:8.3 Jan 15, 2025
3 checks passed
@christianharrington christianharrington deleted the bugfix/cached-collection-race-condition branch January 15, 2025 13:05
markusguenther added a commit that referenced this pull request Jan 15, 2025
…ed-collection-race-condition"

This reverts commit b8dbee8, reversing
changes made to 2b29f53.
@markusguenther
Copy link
Member

Oops! I made a mistake and need to undo the change. I forgot to run the unit tests locally, and they failed because of that change. So, we need to fix that first before we can move forward.

Tak for din contribution @christianharrington ❤️

@christianharrington
Copy link
Contributor Author

Oops! I made a mistake and need to undo the change. I forgot to run the unit tests locally, and they failed because of that change. So, we need to fix that first before we can move forward.

Tak for din contribution @christianharrington ❤️

Should I open a new PR @markusguenther?

@markusguenther
Copy link
Member

That would be very kind :)

@christianharrington
Copy link
Contributor Author

@markusguenther Done so here :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants