-
Notifications
You must be signed in to change notification settings - Fork 123
fix: Add reason to cancelation tasks in tests #526
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
Conversation
Our test-npm-init action was pointed at |
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.
Thanks for the fix!
* fix: Add reason to cancelation tasks in tests * Fix test-npm-init
I just saw this, we should really point at next because otherwise we can’t make breaking changes. |
I was thinking we could set it to `next` in the breaking change PR. And if
there are multiple breaking change PRs at once, you'd set the second to
`next2`.
…On Sat, Mar 12, 2022 at 7:01 PM Roey Berman ***@***.***> wrote:
Our test-npm-init action was pointed at next branch of
samples-typescript, which we haven’t updated since November. We could keep
next, but would need a process for keeping it up-to-date. For now, I'm
just pointing at main until we next need next.
I just saw this, we should really point at next because otherwise we can’t
make breaking changes.
You have a point that next should be updated more frequently.
It’s not high priority though.
—
Reply to this email directly, view it on GitHub
<#526 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB5LGCNZBRXZEOBX4TPQD3U7UV5FANCNFSM5QQHMJDA>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
My preference would be that as part of our release process, we'd upgrade all samples to use the new version and point the |
Without a
cancel.reason
, the test hangs after:Just confirming: even though the proto says reason is optional, it should always be there, and worker should throw & fail when it's not?