SOQL query points to the wrong org

[Luke Kozakewycz]

I can’t work out why - but the SOQL query tool doesn’t seem to return the correct data. I can run the same query in the selected project org using the developer console and it will return completely different results (the correct results).

I am wondering if it is pointing to another org? Could it be down to alias since previous orgs may have used the same alias (the selected project orgs username is correct mind you).

[Luke Kozakewycz]

Just did a clean out of old orgs and force refreshed - now it is showing the correct data. I wonder if it’s using alias instead of username and sfdx is getting confused.

[Scott Wells]

SOQL queries are run directly against the API and not via the CLI. IC uses the access token from the CLI to authenticate, and the CLI should never yield a stale access token (nor should one be allowed as a valid authentication header). If you do see this happen again I'd need to see a debug log to know what's happening.

[Scott Wells]

I'm going to resolve this since it's not an active issue, but needless to say, if it recurs reopen and let's get logs.

[Jurgis Salna]

I def still hit at least once a week, using v2.1.8.7
Apex and SOQL
Def alias related as I often create new org under same alias, then select new org in bottom right. The dropdown in soql/apex windows gets updated with new username, but occasionally still runs against old org.
Lately if I find something is behaving odd I just System.debug(UserInfo.getUserId()); to make sure I'm on the right org, but it still wastes so much time and caused bugs in the past.

‌

[Scott Wells]

Jurgis, I've tried to reproduce this by doing the following:

1. Create a project against a brand new scratch org with alias issue_1804.
2. In the SOQL Query tool window, execute a query against issue_1804, e.g., SELECT Username FROM User and capture the results for comparison.
3. Delete the scratch org with alias issue_1804.
4. Recreate the scratch org with alias issue_1804.
5. Return to the SOQL Query tool window which now shows the selected connection for issue_1804 as red.
6. Execute the same query which yields an INVALID_CROSS_REFERENCE_KEY: invalid cross reference id error.
7. Clicking on the connection drop-down causes it to refresh and pick up the new scratch org connection with the same alias.
8. Execute the query again which succeeds, then verify that the data is in fact from the new scratch org and not from the original scratch org.

I also tried these steps deleting the scratch org outside of IC2 so that it's unaware of the change in status for the project's connected org. In that situation I got the same INVALID_CROSS_REFERENCE_KEY error, and the next time I did anything in IC2 that requires a connection list, it properly picked up that its cache was stale and refreshed it using the CLI.

Aside from the connection going stale due to time instead of being deleted explicitly, anything else come to mind that might help to reproduce this behavior? If not, the next time it happens please capture as much diagnostic information as possible about which org it's incorrectly querying, the statuses of that org and the org that it should be referencing, etc.