Skip to content
This repository was archived by the owner on Oct 16, 2025. It is now read-only.

Suggestion to simplify prevention of dangling Promise on destroy#286

Merged
mikesposito merged 2 commits intofix/internal-listenersfrom
fix/internal-listeners-suggestion
Nov 26, 2024
Merged

Suggestion to simplify prevention of dangling Promise on destroy#286
mikesposito merged 2 commits intofix/internal-listenersfrom
fix/internal-listeners-suggestion

Conversation

@Gudahtt
Copy link
Copy Markdown
Member

@Gudahtt Gudahtt commented Nov 20, 2024

The fix/internal-listeners branch has a number of changes intended to ensure we don't have a dangling unresolved Promise when the block tracker is destroyed. This solution involved adding an additional listener to capture errors, and it involved not removing internal listeners when destroy is called. This required changes to some logging in _updateAndQueue as well.

This commit is an alternative solution that avoids the use of internal listeners, thus avoiding much of the complexity in the previous solution. Instead an internal deferred Promise is used. This also might be slightly more efficient when getLatestBlock is called repeatedly, as we can reuse the same listener rather than creating a new one each time.

@Gudahtt Gudahtt requested a review from a team as a code owner November 20, 2024 23:42
@Gudahtt Gudahtt force-pushed the fix/internal-listeners-suggestion branch from 331159a to f3fe246 Compare November 20, 2024 23:43
The `fix/internal-listeners` branch has a number of changes intended to
ensure we don't have a dangling unresolved Promise when the block
tracker is destroyed. This solution involved adding an additional
listener to capture errors, and it involved not removing internal
listeners when `destroy` is called. This required changes to some
logging in `_updateAndQueue` as well.

This commit is an alternative solution that avoids the use of internal
listeners, thus avoiding much of the complexity in the previous
solution. Instead an internal deferred Promise is used. This also
might be slightly more efficient when `getLatestBlock` is called
repeatedly, as we can reuse the same listener rather than creating a
new one each time.
@Gudahtt Gudahtt force-pushed the fix/internal-listeners-suggestion branch from f3fe246 to 3435c0a Compare November 20, 2024 23:43
// return if available
if (this._currentBlock) {
return this._currentBlock;
} else if (this.#pendingLatestBlock) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good catch here. I was thinking of also using a deferred promise and keeping it in a private field, but it seemed that calling getLatestBlock multiple times without waiting would overwrite that field. This is a good solution.

});
// return newly set current block
return latestBlock;
this.#pendingLatestBlock = { promise, reject };
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering, if we are making this promise available to the rest of the class, would it make sense to also resolve it through this class variable and get rid of the internal listener altogether?

This comment was marked as resolved.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, yeah maybe so, good idea

Comment thread src/PollingBlockTracker.ts
Comment thread src/PollingBlockTracker.ts
@mikesposito mikesposito merged commit e77ed5d into fix/internal-listeners Nov 26, 2024
@mikesposito mikesposito deleted the fix/internal-listeners-suggestion branch November 26, 2024 15:25
mikesposito added a commit that referenced this pull request Dec 3, 2024
* fix: internal listeners infinite retry loop

* edit `CHANGELOG`

* refactor: rename to `#internalEventListeners`

* refactor: simplify listener equality check

Co-authored-by: Mark Stacey <markjstacey@gmail.com>

* Revert "refactor: simplify listener equality check"

This reverts commit eb5514d.

* apply fix to `SubscribeBlockTracker`

* fix: reject `getLatestBlock` promise when block tracker stops

* fix: remove on error internal listener

* Suggestion to simplify prevention of dangling Promise on destroy (#286)

* Suggestion to simplify prevention of dangling Promise on destroy

The `fix/internal-listeners` branch has a number of changes intended to
ensure we don't have a dangling unresolved Promise when the block
tracker is destroyed. This solution involved adding an additional
listener to capture errors, and it involved not removing internal
listeners when `destroy` is called. This required changes to some
logging in `_updateAndQueue` as well.

This commit is an alternative solution that avoids the use of internal
listeners, thus avoiding much of the complexity in the previous
solution. Instead an internal deferred Promise is used. This also
might be slightly more efficient when `getLatestBlock` is called
repeatedly, as we can reuse the same listener rather than creating a
new one each time.

* Unset pending latest block after it has resolved

* fix: operand of a delete operator cannot be a private identifier

* test: change error message

* refactor: add helper methods

* refactor: simplify `SubscribeBlockTracker`

* Update CHANGELOG.md

Co-authored-by: Mark Stacey <markjstacey@gmail.com>

* fix: `SubscribeBlockTracker` throws when subscription fails

* test: remove broken case

* test: add case for returning the same promise

* test: add coverage for `PollingBlockTracker`

* test: add coverage for `SubscribeBlockTracker`

* test: remove redundant tests

* test: check promises return for `SubscribeBlockTracker`

* rename test case

Co-authored-by: Elliot Winkler <elliot.winkler@gmail.com>

* test: spy on `provider.request`

* edit changelog entry

* test: set automatic timer calls to 2

---------

Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: Elliot Winkler <elliot.winkler@gmail.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants