Entity queries for latest revisions should return the latest workspace-specific revisions

Fix is simple enough and comes with test coverage.

Using workspaces both the users and developers should expect to always be working with entities for the current workspace.

@amateescu walked me through this in slack, and it makes sense for workspaces to do this, and it shouldn't cause any side-effects.

All looks good so setting back to RTBC! Tests failure is not related (see #3055648: Frequent random fail in \Drupal\Tests\media_library\FunctionalJavascript\MediaLibraryTest).

So I can see the reasons for doing this, but are there cases where non-workspace-aware code could be querying the latest revision and expects to get the actual most recent revision rather than the workspace-specific one?

#22 is a good argument although seems hard to predict. Let's add both a change record and a release note mention regardless - CNW for that.

Hm, why is this built against 8.7.x and not 8.8.x?

Ok then, I queued a test on 8.8.

Hi, I came across this while investigating what I think is a related issue. I've referenced this issue from #3088341: Add ability to query on most recent language specific revision. I suspect there may be a example found in workspace entity query to borrow and apply to query for the an entity translation most recent revision.

This patch #10 broke SQLite and PostgreSQL.

1) Drupal\Tests\workspaces\Functional\WorkspaceConcurrentEditingTest::testConcurrentEditing
Failed asserting that true is false.

Queued a test against to expose the fails.

build:
  assessment:
    testing:
      run_tests.functional:
        types: 'PHPUnit-Functional'
        testgroups: '--class "Drupal\Tests\workspaces\Functional\WorkspaceConcurrentEditingTest"'
        suppress-deprecations: false
        halt-on-fail: false
        repeat: 10

This time with concurrency: 1.

catch was just asking a question. This change is necessary to ensure predictable behavior with code that is not workspace-aware. I am currently trying to set up workspaces for a major client, and a blocker is that the edit tab does not load the revision for the current workspace by default.

Sure I can share more info. If you have multiple workspaces, the first workspace in which a node is edited blocks editing in all other workspaces because the edit tab always loads the most recent revision. You'll get a message saying the node is being edited in another workspace and changes cannot be saved. The expected behavior is that the most recent live revision is loaded and copied to the current workspace.

I did override the EntityWorkspaceConflict constraint. Also had to apply the fix from this issue.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

The MR needs to be against 11.x since that's the target for commits, the bot isn't wrong there.

This could use an issue summary about why it needs to be done and what the impact is.

Looks great to me!

Had just one question, but that is minor.

Tests also make sense.

FWIW, here is a test summary by AI:

This is a kernel test for Drupal's Workspaces module, specifically testing how entity revisions are managed in different workspaces and languages. Let's break it down:

**1. Key Components:**
- **Workspace Context:** Tests how entities behave when edited in different workspaces ('ham', 'cheese') vs Live environment
- **Multilingual Support:** Tests with English (en) and Romanian (ro) languages
- **Two Entity Types:**
- `entity_test_revpub`: Revisionable, non-translatable entity
- `entity_test_mulrevpub`: Revisionable AND translatable entity

**2. Test Flow:**

**A. Non-translatable Entity Test:**
1. Creates initial entity in Live
2. Creates revisions in workspaces:
- 'ham' workspace revision
- 'cheese' workspace revision
- New Live revision
3. Verifications:
- Each workspace sees its own revision
- Live sees the latest Live revision
- Workspaces maintain their revisions even after Live updates

**B. Translatable Entity Test:**
1. Creates multilingual entity with EN/RO translations in Live
2. Tests workspace-specific translations:
- Creates RO translation revision in 'ham'
- Creates RO translation revision in 'cheese'
- Creates new RO translation in Live
3. Verifications:
- Correct workspace-specific RO translations are returned
- Language context (en/ro) is respected
- Workspace revisions remain isolated from each other and Live

**3. Key Technical Checks:**
- `EntityRepository::getActive()` correctly resolves:
- Workspace context (which revision is active in which workspace)
- Language context (which translation to show)
- Revision tracking across workspaces
- Workspace switching mechanics (`switchToWorkspace()`/`switchToLive()`)
- Proper isolation of workspace-specific revisions

**4. Why This Matters:**
- Ensures content editors in different workspaces don't interfere with each other
- Validates proper version control for multilingual content
- Maintains data integrity when publishing from workspaces to Live
- Tests core Workspaces module functionality at the storage layer

The test uses kernel-level testing (without full HTTP stack) to validate these low-level entity operations efficiently.

Edited code to enhance clarity.

Edited issue summary.

Where it states 'The only impact on existing sites is that entity queries will function properly if the locking protection mentioned above was bypassed in custom code.' in the issue summary should that be 'The only impact on existing sites is that entity queries will not function properly if the locking protection mentioned above was bypassed in custom code.'?

No, Drupal was relying on the locking mechanism to hide this bug from users. Existing sites that bypass the locking mechanism in custom code will now work properly without needing additional workarounds.

@darran oh Great! MR seems good to me.

Rebased.

One question on the MR.

Sorry I completely missed that was the 11.1 MR. However I left one more question on the 11.x MR about an explanatory comment and possibly additional test coverage.

Committed/pushed to 11.x, thanks!

If there were not already 11.1.x and 10.5.x MRs, given this doesn't cleanly cherry-pick, I would have just marked this fixed against 11.x.

In this case there are already backport MRs ready, but this is a non-trivial change and it's not impossible something somewhere could be relying on the existing behaviour (checking if there's a newer revision in a different workspace, maybe?), so I'm still going to leave it fixed in 11.x and not backport - site can download the diff from the 11.1 or 10.5 MRs if they need it before they update. Can possible be persuaded to backport to 10.5.x if it turns out this is needed for contrib compatibility with both 10.x and 11.x but even then probably not to the patch releases.