WINTER '23: All system types are unresolvable/red and missing from the offline symbol table due to Tooling API regression; Salesforce actively investigating

[Gobius Dolhain]

Hey Scott,

When generating an offline symbol table from a Winter 23' org, the System folder is missing, System types like String and List are not available. The Offline Symbol Table only includes managed package types and SObject types.

I cannot include the symbol table because of intellectual property reasons.

I guess this will be fixed once API v56 is implemented?

[Gobius Dolhain]

I was wrong, the System folder does exist, but is lacking a lot of files.

[Gerrit Begall]

Issue #2181 was marked as a duplicate of this issue.

[Bartu B]

It’s not just System by the way, for example the EventBus folder is missing completely.

[Scott Wells]

It sounds like something in the Tooling API's completions resource for Apex has issues in Winter '23. I'll work to reproduce this morning and, if it's something that's under IC2's control I'll issue a hotfix for those working against Winter '23 orgs; if it's something that must be fixed by Salesforce--or actually either way since there shouldn't be breaking changes in published APIs--I'll report to Salesforce. I'll post an update here once I have more information.

[Scott Wells]

Easily reproduced. The issue is that a request for /services/data/v55.0/tooling/completions/?type=apex against a Winter '23 org results in HTTP/1.1 500 Server Error. Interestingly .../completions/?type=visualforce works just fine, so it specifically seems to be a bug/regression for requests for Apex system symbols. I'll report this to Salesforce. The only viable workaround is to generate an OST against a Summer '22 org and copy it into the project as IlluminatedCloud/<connectionName>/OfflineSymbolTable.zip. Hopefully Salesforce can issue a fix quickly.

UPDATE: I've reported this directly to a few of my contacts at Salesforce on the Apex language and tooling teams. Hopefully they'll be able to reproduce themselves and provide a fix (or even a workaround if one exists) shortly.

UPDATE 2: I’m chatting with folks from Salesforce about this now, but I’m able to reproduce it from the org itself without IC2 in the mix at all (note that both v55.0 and v56.0 yield the same issue):

HttpRequest request = new HttpRequest();
request.setEndpoint(URL.getOrgDomainUrl().toExternalForm() + '/services/data/v55.0/tooling/completions/?type=apex');
request.setMethod('GET');
request.setHeader('Authorization', 'Bearer ' + UserInfo.getSessionId());
request.setHeader('Accept', 'application/json');
request.setTimeout(120000);
HttpResponse response = new Http().send(request);
System.debug(response.getBody());

which yields:

13:57:40.272 (1257503627)|USER_DEBUG|[9]|DEBUG|[{"message":"An unexpected error occurred. Please include this ErrorId if you contact support: 1866529118-264305 (-1322588975)","errorCode":"UNKNOWN_EXCEPTION"}]

They’re now examining the logs to see why this would happen, specifically what might have changed since previous platform releases. Hopefully more to come soon.

UPDATE 3: Okay, Salesforce has correlated the underlying cause of this to a related issue that is scheduled to be fixed in their Winter ‘23 4.x patch release that should go out in the next few days. In the interim, the only real workaround for those who must work against Winter ‘23 preview orgs will be to generate an OST from another org and use it as described above. It sounds like the need for that workaround should be quite short-lived, though, and as soon as I hear that the patch is out, I’ll verify the fix and report back here.

UPDATE 4: I’ve confirmed that the Winter '23 4.x patch resolves this issue. Once that patch is in your org/instance you should be able to generate an OST against that org and have a complete OST for it. If you find that not to be the case and have confirmed your org to be on Winter '23 Patch 4.0+, please let me know so I can report it to Salesforce.

[Scott Wells]

Issue #2183 was marked as a duplicate of this issue.

[Scott Wells]

For those watching for new information, I’ve updated the pinned response here with the latest from Salesforce. There should be a fix for this in the next few days. No changes should be needed in IC2; it should just be a matter of regenerating your OST once your org’s instance is updated with Winter '23 Patch 4.x.

[Scott Wells]

Issue #2184 was marked as a duplicate of this issue.

[Tony White]

Looks like Winter '23 patch 4.0 has been released - https://trailblazer.salesforce.com/issues_releases_view?release=240004000

And the above anonymous script worked without issue. (phew)

And refreshed the OST for Objects and it appears good now

[Scott Wells]

I can confirm that the Winter '23 4.x patch resolves this issue. I don't know if Salesforce has rolled out the patch 100% already, but once it's in your org you should be able to generate an OST against that org and have a complete OST for it. If you find that not to be the case and have confirmed your org to be on Winter '23 Patch 4.0+, please let me know so I can report it to Salesforce.

[Miles Robson]

https://status.salesforce.com/instances/CS214 , Version Winter '23 Patch 5.5

Any System.assert with just a bool expression seems to be failing, but I can see them in the symbol generation? Not sure if that matters.

Happening on a net new project right now, as well. Other

`Cannot resolve symbol 'assert'`

Seems to also be happening on Winter '23 Patch 5.7, CS166

Not seeing any other broken symbols.

[Scott Wells]

Miles, have you updated to last week’s build?

https://illuminatedcloud.blogspot.com/2022/09/2235-release-notes.html?m=1

specifically:

• Issue 2190 - Winter '23 introduces a new System.Assert class as an alternative to the traditional System.System.assert* methods. This created a slight resolution ambiguity for IC2 between the System.assert() method and the new System.Assert type which has been addressed in this build.

Let me know if you still see the issue after updating to 2.2.3.5+.

[Miles Robson]

That’ll do it. My mistake, thanks!