Skip to content
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

fix: always catch and emit cache write errors in promise #288

Merged
merged 3 commits into from
Jan 29, 2024

Conversation

lukekarrys
Copy link
Contributor

No description provided.

@lukekarrys lukekarrys requested a review from a team as a code owner December 7, 2023 18:54
@@ -274,6 +274,10 @@ class CacheEntry {
const cacheWritePromise = new Promise((resolve, reject) => {
cacheWriteResolve = resolve
cacheWriteReject = reject
}).catch((err) => {
Copy link
Member

Choose a reason for hiding this comment

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

This would be from when we called (reject) so why not emit it there?

This may be a nitpick.

Copy link
Member

Choose a reason for hiding this comment

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

line 302

cacheStream.promise().then(cacheWriteResolve, cacheWriteReject)

the error function should emit imho.

cacheStream.promise().then(cacheWriteResolve, err => {
         if (body) {
          body.emit('error', err)
        }
   cacheWriteReject(err)
})

(typed on the website, syntax may be all wrong).

Copy link
Member

Choose a reason for hiding this comment

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

Confirmed w/ nlf. The error is the lack of an emit when rejecting, we shouldn't need a catch we should just be sure to emit when rejecting. It's also more intuitive, it's harder to reason why we're doing a blanket catch versus having an emit before we reject.

I think this also eats the rejection.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with moving the emitting to line ~302.

if (body) {

We can drop the if. At line 302 we know there's a body. In fact we were called by the body's resume handler.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So far I've learned there has to be a catch attached to the promise immediately, otherwise the cache dir creation error is unhandled. So if the catch needs to be there then we also need to emit from there. But I'm still not sold on my fix being the correct one, only that emitting from a different place does not fix the test case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also dropped the if (body) statement as suggested since it was not necessary.

@@ -274,6 +274,10 @@ class CacheEntry {
const cacheWritePromise = new Promise((resolve, reject) => {
cacheWriteResolve = resolve
cacheWriteReject = reject
}).catch((err) => {
if (body) {
Copy link
Member

Choose a reason for hiding this comment

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

What if there is no body? Do we still need to emit an error event so the stream is cleaned up?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@hashtagchris pointed out that there will always be a body in this so I removed the if statement guard.

}).catch((err) => {
if (body) {
body.emit('error', err)
}
})

body = new CachingMinipassPipeline({ events: ['integrity', 'size'] }, new MinipassFlush({
Copy link
Contributor

Choose a reason for hiding this comment

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

We don't need to declare the error event, do we?

Suggested change
body = new CachingMinipassPipeline({ events: ['integrity', 'size'] }, new MinipassFlush({
body = new CachingMinipassPipeline({ events: ['integrity', 'size', 'error'] }, new MinipassFlush({

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don't since that event is always raised on the stream and is not a new event that we need to inform the caching stream of like integrity and size.

@@ -274,6 +274,10 @@ class CacheEntry {
const cacheWritePromise = new Promise((resolve, reject) => {
cacheWriteResolve = resolve
cacheWriteReject = reject
}).catch((err) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with moving the emitting to line ~302.

if (body) {

We can drop the if. At line 302 we know there's a body. In fact we were called by the body's resume handler.

@lukekarrys lukekarrys merged commit ed73ef5 into main Jan 29, 2024
20 checks passed
@lukekarrys lukekarrys deleted the lk/uncaught-promise branch January 29, 2024 19:17
@github-actions github-actions bot mentioned this pull request Jan 29, 2024
wraithgar pushed a commit that referenced this pull request Apr 30, 2024
🤖 I have created a release *beep* *boop*
---


##
[13.0.1](v13.0.0...v13.0.1)
(2024-04-30)

### Bug Fixes

*
[`66018e3`](66018e3)
log errors on retry (@wraithgar)
*
[`ed73ef5`](ed73ef5)
[#288](#288) always catch
and emit cache write errors in promise (#288) (@lukekarrys)

### Chores

*
[`9e1329c`](9e1329c)
[#292](#292) fix linting in
tests (@lukekarrys)
*
[`4756bda`](4756bda)
[#292](#292) postinstall
for dependabot template-oss PR (@lukekarrys)
*
[`91df666`](91df666)
[#292](#292) bump
@npmcli/template-oss from 4.21.3 to 4.21.4 (@dependabot[bot])

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants