-
Notifications
You must be signed in to change notification settings - Fork 206
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(notifier): Add makeNotifierFromSubscriber #5737
Conversation
packages/notifier/src/notifier.js
Outdated
harden(makeNotifierFromSubscriber); | ||
|
||
/** | ||
* Deprecated adaptor from async iterable to notifier. |
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.
https://www.typescriptlang.org/play#example/jsdoc-deprecated
* Deprecated adaptor from async iterable to notifier. | |
* @deprecated adaptor from async iterable to notifier. |
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.
Also please explain here why it's deprecated.
I have intentionally included the changes from #5695 along with an immediate reversion for posterity.
I request that those two commits be omitted (or this be landed as squash). For master it's noise. If there's something important to convey about how we got to this point then just write it in HEAD. If you want there to be some record of the other work done, it's already in the referenced PR.
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'm anticipating the attempt to come up again, and would like the prior record to outlive that dead branch.
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.
The branch will be dead but #5695 will endure for anyone who wants to see it.
Non-blocking but I do think the PR suffices as a record and to the point of discover as to why this is the design, I don't think commit history suffices. If that's the goal is should be written into HEAD.
|
||
const sequence = []; | ||
const firstP = notifier.getUpdateSince(); | ||
firstP.then(_ => sequence.push('resolve firstP')); |
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.
please address the floating promises on 250 and 252
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.
Address in what 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.
make the warnings go away :)
either by awaiting or putting void
to indicate it need not be awaited. (the warning string explains another option is to .catch
but that seems silly here)
// /////////////////////////////// makeNotifierFromSubscriber ///////////////////////////////// | ||
|
||
/** @param {{conclusionMethod: 'finish' | 'fail', conclusionValue: any}} config */ | ||
const makeGeometricPublishKit = ({ conclusionMethod, conclusionValue }) => { |
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.
this sounds like it's making a PublicKit but it's returning something different.
const makeGeometricPublishKit = ({ conclusionMethod, conclusionValue }) => { | |
const makeGeometricPublishHelper = ({ conclusionMethod, conclusionValue }) => { |
Looks like calls have the same arguments. Why parameterize?
const makeGeometricPublishKit = ({ conclusionMethod, conclusionValue }) => { | |
const makeGeometricPublishHelper = () => { |
Also looks like all tests share this first line. Once this is in its own file, it would work well to put in a hook:
test.beforeEach(t => {
Object.assign(t.context, makeGeometricPublishHelper());
}
Or even,
test.beforeEach(t => {
Object.assign(t.context, makeGeometricPublishHelper());
t.context.notifier = await makeNotifierFromSubscriber(t.context.subscriber);
}
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.
Renamed for clarity, but kept it outside the test context.
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.
Makes sense. I was wrong about the parameterization
packages/notifier/src/notifier.js
Outdated
* @param {ERef<Subscriber<T>>} subscriberP | ||
* @returns {Promise<Notifier<T>>} | ||
*/ | ||
export const makeNotifierFromSubscriber = async subscriberP => { |
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.
export const makeNotifierFromSubscriber = async subscriberP => { | |
export const makeNotifierFromSubscriber = async subscriber => { |
I assume P
is for "Promise" but that's not exactly what this is.
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.
It's an ERef, which may be a promise. I think we do use this pattern to highlight that potential.
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've also seen P
for Presence, kind of the opposite.
I don't think we have any consistent guidelines on this but I would make the case that when possible we rely on the type system for whether something is a promise or not. If there's no need to bind both the promise and the resolved value then use the simpler name. non-blocking request.
3b14845
to
137088c
Compare
Eager consumption led to infinite loops; see #5695 for context.
137088c
to
f40b7ed
Compare
@turadg f40b7ed addresses everything except the "floating promises" concern... what kind of change are you expecting for that? |
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.
LG. I'll approve when the three new eslint warnings are resolved.
I didn't see the promise ones locally. Anyway, resolved and pushed. |
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.
👍
packages/notifier/src/notifier.js
Outdated
* @param {ERef<Subscriber<T>>} subscriberP | ||
* @returns {Promise<Notifier<T>>} | ||
*/ | ||
export const makeNotifierFromSubscriber = async subscriberP => { |
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.
This isn't an async function:
export const makeNotifierFromSubscriber = async subscriberP => { | |
export const makeNotifierFromSubscriber = subscriberP => { |
I don't think it needs to return Promise
either. Can't it return the Notifier
as makeNotifierFromAsyncIterable
does?
Working on #5704 I ran into some issues using this so I took another look and found a few things to address:
|
getUpdateSince() always consults the source subscribeAfter() rather than using a possibly-stale local cache.
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 rebased my branch onto this version and the contract tests pass!
😸
* fix(notifier): Make makeAsyncIterableFromNotifier lossy Cherry-picked from gh-5413-lossy-makeNotifierFromAsyncIterable. See #5695 . * fix(notifier): Revert "Make makeAsyncIterableFromNotifier lossy" Eager consumption led to infinite loops; see #5695 for context. * feat(notifier): Add makeNotifierFromSubscriber Fixes #5413 * test(notifier): Update per code review * chore(notifier): Resolve lint warnings * fix(notifier): Align makeNotifierFromSubscriber with makeNotifierKit getUpdateSince() always consults the source subscribeAfter() rather than using a possibly-stale local cache. * fix master merge Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> Co-authored-by: Turadg Aleahmad <turadg@agoric.com>
Fixes #5413
Description
Add
makeNotifierFromSubscriber
for lossy consumption of PublishKit subscriber objects viasubscribeLatest
(eachgetUpdateSince()
call returns a unique already-settled promise for the latest result, eachgetUpdateSince(lastUpdateCount)
call requests the next value [which under the covers constructs a new iterator] and returns a unique promise for it).Also deprecates
makeNotifierFromAsyncIterable
.This PR should land with a rebase rather than a squash; I have intentionally included the changes from #5695 along with an immediate reversion for posterity.
Security Considerations
None known.
Documentation Considerations
Agoric/documentation#684
Testing Considerations
More tests to come before merging.