I found a strange behavior about externally described data structures (e.g. extname) if I'm using a local workspace.
While opening a source file, the parser.js tries to resolve the underlying files via "fetchTable".
If no cache has yet been detected, this will get sent forward up to the request handler (request.ts > client.onRequest(getObject).
There, you first check for an instance of a CodeForI extension.
If my source is already open at client startup, then it usually happens that there's no instance yet - which leaves me with an empty array as a result. This array gets cached, so there's no field list. I'm not sure if this only applies if you're trying to debug the vscode-rpgle extension or if this would apply to the standard user as well (I can't check the latter anyhow).
Now furthermore, if the instance already exists, you're checking the IBM i connection before fetching the field list. If I'm including copybooks from a source file/IFS then vs code automatically establishes a connection to IBM i.
But if you're only using local source files, then there's no automatic connection (which is bad for fetching field lists, I guess...).
This also leads to a cached file with no fields in it.
As we moved away from source files to a git repo with an local-only workspace, we now have to close every open editor before closing vs code, because if we're starting it up again, we have to manually connect first and only then can we open rpg sources - if not, then every file is being cached with an empty field list.
This leads me to 2 questions:
1) Would it be feasible to automatically connect to IBM i if you're opening a source with externally described data structures prior to fetching said table information?
2) Would it also be feasible to simply not cache information about a file, if no instance or connection has been established? If the connection is established but the file really doesn't exist, you can still return an empty array and cache that. The parser would keep on retrying to fetch the field list until a connection is set up, but at least that's not hurting IBM i ressources. Still you could stop the table fetch anyhow as long as there's no active connection.
For my second question, I did the following code changes as a test:
in requests.ts > client.onRequest, I added else cases for instance and connection checks and returned null in these two cases
in server.ts > parser.setTableFetch, i checked if (data) before returning dspffdToRecordFormats and threw some specific error in the else case
in parser.js > fetchTable, I extended the catch (e) logic and checked for the specific error. If it applied, I simply set this.tables[existingVersion] to null and returned an empty array, else I used the existing logic ("Failed. Don't fetch it again").
I may be totally on the wrong track with this one, but I didn't find any similar issue or a possible misconfiguration on my side.
I found a strange behavior about externally described data structures (e.g. extname) if I'm using a local workspace. While opening a source file, the parser.js tries to resolve the underlying files via "fetchTable". If no cache has yet been detected, this will get sent forward up to the request handler (request.ts > client.onRequest(
getObject).There, you first check for an instance of a CodeForI extension. If my source is already open at client startup, then it usually happens that there's no instance yet - which leaves me with an empty array as a result. This array gets cached, so there's no field list. I'm not sure if this only applies if you're trying to debug the vscode-rpgle extension or if this would apply to the standard user as well (I can't check the latter anyhow).
Now furthermore, if the instance already exists, you're checking the IBM i connection before fetching the field list. If I'm including copybooks from a source file/IFS then vs code automatically establishes a connection to IBM i. But if you're only using local source files, then there's no automatic connection (which is bad for fetching field lists, I guess...). This also leads to a cached file with no fields in it.
As we moved away from source files to a git repo with an local-only workspace, we now have to close every open editor before closing vs code, because if we're starting it up again, we have to manually connect first and only then can we open rpg sources - if not, then every file is being cached with an empty field list.
This leads me to 2 questions: 1) Would it be feasible to automatically connect to IBM i if you're opening a source with externally described data structures prior to fetching said table information? 2) Would it also be feasible to simply not cache information about a file, if no instance or connection has been established? If the connection is established but the file really doesn't exist, you can still return an empty array and cache that. The parser would keep on retrying to fetch the field list until a connection is set up, but at least that's not hurting IBM i ressources. Still you could stop the table fetch anyhow as long as there's no active connection.
For my second question, I did the following code changes as a test:
I may be totally on the wrong track with this one, but I didn't find any similar issue or a possible misconfiguration on my side.