Cfindex not indexing .docx word documents files

OK, guys. It's been a long day (working almost entirely on this issue).

1) First, yes BKBK. You are right in that if Keith were to upgrade to u15 and THEN do that downgrade, that will indeed downgrade the search package and should his process to work. Same if he wanted to stay on u14 for some reason and just get the cfindex docs processing working there (but getting updated to u15 is a worthy goal, of course)..

Keith, that's likely your primary goal and so proceed with either of those. You can read on if you like (especially with regard to why the uninstall of u14 still left things amiss), but I don't know if most of it will interest you as much as I hope it will BKB and perhaps others. 🙂

2) So as I alluded to I was focused more on other related things.

One is that he had reverted to u14 (at least he said he had, and his concern was that things still didn't work there). And I think you and he will find that it works also if he does that there. (I actually haven't tested that--though I'd wanted to--as I've been working on the larger problem.) And to be fair, I even said so before your "stop the world" lament, where I agreed that 'downgrading the search package alone may well "work" for what you tested, but it's not the COMPLETE solution'. 

And I want to repeat that I DID file the bug report with Adobe to try to get them to figure out why his cfindex of a docx fails with that update to 15 (like it does also for those who update to the latest 2023 or 2021 updates). I want to say first that I totally agree that uninstalling the latest search package IS a workaround for that. You'll want to add that to the bug report, to help others beyond this thread.

3) But thre is a larger problem, which has been my main focus, where in fact the package stayed on u15 even though he uninstalled u15.  As I noted, it affects also MORE than that one package, and more than CF2023 (but also 2025 and 2021). And that is the "exciting" news I'd been wanting to share.

But I also had wanted to help someone like him--who was on 14 and installed 15 and had a problem, then uninstalled. It was your solution and MORE. I'd found that 6 of the CF2023 packages were still on their u15 versions--even after the uninstall of u14. THAT's what caught my attention. As I'd reported earlier today, those 6 (for CF2023) are axis, exchange, saml, search, sharepoint, and 
spreadsheet. And while one could manually uninstall each (like you'd had him do that search one), I'd studied the 6 and determined what the previous version of each would be. One could downgrade them via cfpm (to do all 6 at once)

cfpm install axis:2023.0.11.330706,exchange:2023.0.11.330706,saml:2023.0.11.330706,search:2023.0.11.330706,sharepoint:2023.0.11.330706,spreadsheet:2023.0.05.330608

(Sadly, there's no simple downgrade optionin CFPM, to just revert from the current version to the earlier one.) Of course, for CF2025 or cf2021 those would be different values, but since Keith was only focused on CF2023 I will leave it at that.

And sorry, but when I wrote last night saying I wasn't sure if what you offered would work, it's just that I had that more complete solution in mind (beyond just what KEith was facing--but I appreciate you were focused more on that.)  

4) But moving on to the much larger problem (why the uninstall didn't downgrade them), that was the MOST exciting info I'd found--and what I especially thought you may appreciate.

What I've found is that the problem is in fact a mistake in the bundlesdependency.json file. I'd never studied it closely before yesterday, and as I did, I figured out not only THIS problem (how Keith's uninstall of u15 back to 14 did NOT downgrade those 6 packages), but it ALSO explains MANY of the problems with package management that we've seen her ein the forums--not just with this update but with several over the years.

5) So what's the issue? Well, if you look closely at the json, it's an array with an element for each package and then for that package what its "version" is (like 2023.0.11.330706, for that search version we would hav ehim downgrade to). But then also for MOST (but not ALL) of those package array elements it also indicates a "minimumcoreserverupdaterequired" value. That might be set to 11, such as is the case for that search package he would downgrade to.

But the PROBLEM is that SOME of the packages (these 6 for cf2023 u15, in fact) mistakenly have that that minimumcoreserverupdaterequired value set  ALSO to 11--when they SHOULD be set to 15. And this is in fact that case for that search package, where the one updated for u15 (whose "version" is  2023.0.15.330825) instead ALSO shows its minimumcoreserverupdaterequired=11.

And THAT is why when u15 was uninstalled, CF mistakenly thought, "oh, I can leave that u15 version of search in place, because it works with a core version as low as 11". But in fact that's wrong.  And indeed ANYtime the version of the package exceeds that minimumcoreserverupdaterequired, it's going to lead to this problem.

(And FWIW, it's not ALL of the packages that WERE updated with 15 that have the problem. Several have the CORRECT minimum core value of 15, such as u15's packages for document, scheduler, image, presentation, and others.)

And there are still other examples within that json file where some packages have NO value set for that min core version. Those, too, suffer from this problem (if one is on an older CF update and says to install or update such a package, it won't STOP them even if the package version would be greater than their current core version.) It's really quite a mess. More on finding those in a moment.

6) But there are still other implications of this problem. For instance, as you may know, if you are on one CF version and you tell CF to upgrade a package to a higher version, the CF Admin (or cfpm) should WARN you that doing so would cause CF itself to be upgraded. (Many don't notice that prompt when updating via the Admin UI, as it's just another sentence on the prompt to confirm doing the update.)

The point is that you DO get that prompt for those packages where the min core version value for the package HAS been made equal to the package's version (so 15, for a package whose version is that 2023.0.15.330825 value). But you DON'T get it for these ones where the min core version value is LESS than the package version. And THAT's one way to get in trouble, again whether from the Admin or cfpm.

Besides the 6 wrong for CF2023 update 15, there are 5 for cf2025 u3 (if one is on an earlier update and installs any of those 5 packages, they will get the u3 version unexpectedly) and 7 for cf2021 update 21.

But to be clear, this problem will happen to ANYONE on ANY version earlier that the LATEST CF update, not just one behind the latest. And it's ALSO been a problem for several previous updates.

7) In fact, I created a cf template that anyone can use to perform this very analysis.  It's just a single simple cfm file (broken into functions, for readability).

It lets one specify the CF version they want to test, and what update level they may be on, then it looks at the bundlesdependency.json to determine if nay packages have this problem I'd dicussed above (either the mincore version is LOWER than that package's "version" value or there is NO mincore version for that package).

That code is attached. But since the forums here only let us upload certain file extensions, just change it to a cfm, then save it somewhere that you can run code, and give it a try. Once I hear any feedback I would consider posting it instead to github--so that those interested could track if it changes over time. It's been a very long day, which is another reason I'll hold off on that for now. 

😎 So this is a bug in the current bundlesdependency.json file, one that Adobe needs to solve. Again, I want to see what you guys think even before I file a bug report. I realize it's been a LOT to read.

Again, in summary, yes for someone in Keith's situation on either cf2023 u15 or 14, he can just downgrade his search package to the u11 version of that. That will get his cfindex code working as expected. But he will still have an updated POI library from some of the OTHER 5 packages suffering this problem in that version. I offered that cfpm install with the corrected versions to help there. (Folks on older updates of the other two CF versions can use this info to figure out what they should do, if they want to automate downgrading their packages which were incorrectly updated, or not correctly downgraded when they uninstalled the latest update.)

But the real crux of the problem is in the mistaken bundlesdepdency.json (which gets downloaded if the "package site" url is set to the default, which for cf2023 is https://www.adobe.com/go/cf2023_packages). And it's happening in all 3 versions, and for updates even before this latest one. This mess REALLY starts to explain why it has been so difficult and confusing to understand some problems people have had. It gets still more confusing when people may DOWNLOAD the json file and might get a different version even once Adobe updates it.

And that's why I really wanted to get this documented here, for us in this thread and eventually to spread the news more widely--and press Adobe for a correction (to all the misconfigurations in all 3 json files). With that, it's beddy bye time. If I've made any mistakes, my apologies. It's been a LOT to juggle, research, organize, distill, write about, etc. Again, sorry for the abruptness earlier.