fix(test): resolve flaky ContentMapTest by using WAIT_FOR index policy (#34600)

[spbolton]

Summary

Fixes flaky tests ContentMapTest.testGetRecycledRequest and testGet_showCategories_AsAnonUser by addressing the root cause: findAllContent was using Elasticsearch which can have stale entries after content deletion.

Changes

1. Fixed ESContentFactoryImpl.findAllCurrent to use database queries instead of Elasticsearch

   • Queries contentlet_version_info table directly for working contentlet inodes
   • Filters out null entries (content deleted but version info not yet cleaned up)
   • Database is the source of truth, ES index can have stale entries

2. Added ContentletDataGen.findAllContent test utility

   • Provides a reliable DB-based method for test code
   • Same implementation approach as the production fix

3. Deprecated ContentletAPI.findAllContent

   • Method is only suitable for tests, not recommended for production use
   • Added @Deprecated annotation across all API layers:
     • ContentletAPI.java (interface)
     • ESContentletAPIImpl.java (implementation)
     • ContentletAPIInterceptor.java
     • ContentletAPIPreHook.java
     • ContentletAPIPostHook.java

4. Updated tests to use new test utility

   • ContentMapTest
   • ContentletIndexAPIImplTest
   • PushedAssetsAPITest
   • ContentletAPITest

5. Added IndexPolicy.WAIT_FOR to ContentletDataGen destructive methods

   • archive(), delete(), destroy() now wait for ES index updates
   • Ensures index is consistent after content modifications in tests

Root Cause

The Elasticsearch index can have stale entries when content is deleted from the database but not yet removed from the ES index. By querying the contentlet_version_info table directly and then loading contentlets by inode, we ensure we only get valid, existing content.

Test plan

• Run ContentMapTest.testGetRecycledRequest - passes consistently
• Run ContentMapTest.testGet_showCategories_AsAnonUser - passes consistently
• CI pipeline passes

🤖 Generated with Claude Code

Closes #34600

This PR fixes: #34600

[spbolton]

@wezell In this case it seemed that the DataGen was actually using DEFER by default when removing. This actually triggered the code in com.dotcms.content.elasticsearch.business.ESContentFactoryImpl#findAllCurrent(int, int) to still find the removed items in search, but the db in the internal find() method in that class already saw the item removed. This lead to the result list containing null entries as the null result from find() was being added to the list. At the moment the test case has been updated to skip these null cases and we should now be ensuring that the search state is correctly updated anyway, but should we update the source of findAllCurrent to just skip null results from find()

[wezell]

I think this is the wrong fix for a few reasons.

1. findAllContent should be using the db not ES
2. If there are still null entries, these should be filtered out in the API and not in the test

Here is what the method should look like (this is untested but you get the idea):

        final long ultimateLimit = Math.min(limit, ESContentletAPIImpl.MAX_LIMIT);

        List<Contentlet> contentlets = new ArrayList<>();

        try {

            final DotConnect dotConnect = new DotConnect("select working_inode from contentlet_version_info limit " + limit + " offset " + offset);
            dotConnect.addParam(ultimateLimit);
            dotConnect.addParam(offset);
            List<Map<String, Object>> results = dotConnect.loadObjectResults();
            for (Map<String, Object> result : results) {
                contentlets.add(find((String) result.get("working_inode")));
            }
        }catch(Exception e){
            throw new DotRuntimeException(e);
        }

        return contentlets;
****

        return contentlets;

[wezell]

Also, it does not look like findAllContent method is being used anywhere except in tests? Am I right about that? If so, let's depreciate it as it can be a server killer

[wezell]

This looks great, thanks.

[dcolina]

Go for it.