You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once #195 & #219 is resolved it's likely that a number of edge cases will emerge.
Error messages may not be as helpful as we'd like them to be and the UX overall may need some enhancements, but it's not clear yet how to best address all these edge cases, so I'm creating this issue to track it and brain dump some known unknowns.
When we add a new root module, we always discover module manifest and plugin lock file locations, just so they can be tracked by the watcher.
There is however a number of operations which run asynchronously after adding the module roughly in the following order
parsing module manifest
discovering terraform executor
obtaining terraform version
finding compatible language parser (there's just one for now, but it's gated on 0.12+)
Any of the above can either be in progress of loading - i.e. not done yet when the user is e.g.
requesting completion
requesting formatting
or any of these can fail, which makes any functionality depending on it to error out, e.g.
unreadable module manifest
no terraform found in $PATH
no terraform version found (e.g. because of tfenv unparseable output, or binary being un-executable)
no compatible parser found (e.g. because of too old TF version)
no compatible schema storage found (e.g. because of TF 0.11 and older)
failed to obtain schema (e.g. because of missing backend auth, invalid config or other reasons)
The question is how should these edge cases be communicated, if at all to the user and when.
There was an attempt to surface some of this in #187 but surfacing TF errors will generally require some better handling. Also we should aim to keep the messaging relevant in time or per event (see #212)
The text was updated successfully, but these errors were encountered:
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the context necessary to investigate further.
ghost
locked and limited conversation to collaborators
Aug 13, 2020
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Once #195 & #219 is resolved it's likely that a number of edge cases will emerge.
Error messages may not be as helpful as we'd like them to be and the UX overall may need some enhancements, but it's not clear yet how to best address all these edge cases, so I'm creating this issue to track it and brain dump some known unknowns.
When we add a new root module, we always discover module manifest and plugin lock file locations, just so they can be tracked by the watcher.
There is however a number of operations which run asynchronously after adding the module roughly in the following order
Any of the above can either be in progress of loading - i.e. not done yet when the user is e.g.
or any of these can fail, which makes any functionality depending on it to error out, e.g.
$PATH
tfenv
unparseable output, or binary being un-executable)The question is how should these edge cases be communicated, if at all to the user and when.
There was an attempt to surface some of this in #187 but surfacing TF errors will generally require some better handling. Also we should aim to keep the messaging relevant in time or per event (see #212)
The text was updated successfully, but these errors were encountered: