Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
imp(core): allow huckleberry events with a prefix #5541
imp(core): allow huckleberry events with a prefix #5541
Changes from 10 commits
c53f913
688a9d9
70e7cad
bdbd9f6
88f430b
f4caa14
da528e4
b5f6ee0
6a2bef0
07fca7e
78a1c60
1c7862f
43a03f3
986fc82
16a3312
52b1e0e
a30078b
fae32e4
6106643
4b58d7f
4f9acf3
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
you could consider refactoring these test cases to use a function that asserts the expected test outcomes as in this pr rather than checking against these
if
conditions, might be easier to read. but can also be done in a followupThere 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.
Yeah, we could do it. I think this better be a followup because these "if conditions" are already used commonly in this file for
async
. So, such a refactor would change unrelated testing code tooThere 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've moved some parameters to the test case like @chatton suggested. However, we could still open an issue for your suggestion since I think it could be a nice improvement
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.
small nit, to be more consistent maybe we could make this a
tc.replay
, we seem to be mixing things liketc.expPass
and standalone bools likereplay
.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.
done
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.
can we elaborate on this reasoning? I feel it is safer to prefix the type as well. Is there a direct benefit to not prefixing the type?
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 thought it might be easier for users to index events by module that emitted the event. In that it wouldn't break their pre-existing clients too much.
The reasoning isn't solid but what I meant was that event types are only used for indexing attributes by module. Event types aren't the key to some value, they are only used to retrieve the attributes.
But I'm open to prefixing this too
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.
Hmm yea. My main concern is accidental misuse, that is using the event type to indicate an action occurred without caring about particular values. But I think you make a fair point that event types aren't the key to some value. I'm not too concerned about breaking pre-existing clients as pre-existing clients currently cannot access error events. If the primary use case here is simply for debugging, I'm not sure I see much benefit in not error prefixing the type defensively, but I don't feel strongly, just feel slightly uncomfortable allowing any surface area for misinterpretation of events
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.
Yeah fair enough. Added the prefix here as well