fix: gracefully handle cases where content URIs are invalid #26
Conversation
As discussed in aragon#167, `apm versions` throws when any of the returned content URIs are invalid. This behaviour will be fixed with aragon/apm.js#26, so now we're making use of that exposed error or warning message for a better user experience. Closes aragon#167
src/index.js
Outdated
| reportType = 'warning' | ||
| } else if (!providers[provider]) { | ||
| errorMsg = `Provider: ${provider} is not supported` | ||
| reportType = 'error' |
There was a problem hiding this comment.
As mentioned in the call, I first thought it could be useful to make APM export the different errors types as constants (or preferably enums if we had TypeScript), but I obviously wasn't able to think straight.
For now I went with exposing the report type, so we can make decide on the call side whether we wanna show a warning or an actual error. Let me know if you prefer a different way of exposing this information.
src/index.js
Outdated
| reportType = 'warning' | ||
| } else if (!providers[provider]) { | ||
| errorMsg = `Provider: ${provider} is not supported` | ||
| reportType = 'error' |
src/index.js
Outdated
|
|
||
| if (!provider || !location) { | ||
| errorMsg = `contentURI: ${contentURI} is invalid.` | ||
| reportType = 'warning' |
There was a problem hiding this comment.
I think we can remove reportType from here and always report a warning in the CLI.
|
I think this PR is a good opportunity to fix this as well: #27 |
0x-r4bbit
force-pushed
the
fix/get-application-info
branch
from
19bba70 to
85056ff
Compare
As discussed in aragon#167, `apm versions` throws when any of the returned content URIs are invalid. This behaviour will be fixed with aragon/apm.js#26, so now we're making use of that exposed error or warning message for a better user experience. Closes aragon#167
|
Hi! Can you fix these lines also? Lines 88 to 98 in 85056ff This will fix my issue! Thank you |
Prior to this commit, all content URIs of application versions are expected to follow the format `<provider>:<identifier>`. In case a content URI doesn't follow this format, an error is thrown. We now ensure that in such cases, the code still executes but resolves early with an error or warning respectively. It also fixes aragon#27 where parsing content URIs that contain more than one split character (e.g. `:` in `http://localhost:8080/foo/bar`) splits the `identifier` as well (which we don't want). Fixes aragon#20, aragon#27
0x-r4bbit
force-pushed
the
fix/get-application-info
branch
from
85056ff to
d53212f
Compare
|
@deamme thanks for the heads-up! I've updated it, can you please verify? |
|
@PascalPrecht Works, thanks! |
Prior to this commit, all content URIs of application versions are
expected to follow the format
<provider>:<identifier>. In case acontent URI doesn't follow this format, an error is thrown.
We now ensure that in such cases, the code still executes but resolves
early with an error or warning respectively.
Fixes #20