-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: adding _OP_FAILED_KEYS and FAILED_KEYS #422
Conversation
5b8ac40
to
cb50474
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great to surface this information. Looks good, aside from a couple of comments on ensuring the messages are correct.
(I took the liberty of marking the later story as a duplicate - please yell at me if we want something else). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As being discussed on Slack, I like the idea of a single key whose value is an array of "key that couldn't be reported, and reason" as a long-term design. Otherwise we might end up wanting to add quite a few _FOO_FAILURE_REASON
keys. But I think we can handle that later.
LGTM (though see nit).
this will allow to report any other future failures in a generic way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also like that this avoids complexity of whether a user who subscribes to FOO
should consider whether they also subscribe to FOO_FAILURE_REASON
(which may even be added after FOO
, as it would've been for _OP_CLOUD_METADATA_FAILURE_REASON
).
Sure, we could imagine behavior like "subscribing to FOO
also subscribes to a corresponding FOO_FAILURE_REASON
key", and have that behavior configurable by another key, but the current design seems better to me. I suppose a trade-off is that a user currently isn't able to opt-out of particular keys being reported in FAILED_KEYS
if they don't care about them, but a user subscribed to FOO
probably does often care about that key being missing. And that opt-out could always be added if anyone wanted it.
Looks good, but can we clarify the error description for the hop limit a little further?
Co-authored-by: ee7 <[email protected]>
CHANGELOG.md
if necessaryIssue
when we know exact reason why imds failed we should make it explicit in the report
Description
reports when chalk knows exact reason for the failure. currently thats when we get explicit 403 which implies metadata is disabled for that instance of we see
readLine
timeout which implies hop limit is reached. Other failure modes we cant account for so dont report anything onTesting