Upload streaming is probably broken in the presence of partial failure

[j-baker]

We retry all IOExceptions, but what if we already consumed some bytes from the InputStream?

[j-baker]

(you'll get a partial body)

[stale[bot]]

This issue has been automatically marked as stale because it has not been touched in the last 60 days. Please comment if you'd like to keep it open, otherwise it'll be closed in 7 days time.

[uschi2000]

@iamdanfox I'm sure closing all these issues automatically is the right move since many a legit problems and many people use issues as a long-term memory.

[iamdanfox]

Happy to re-open any you think should deserve PRs. I'm considering stalebot really as just a forcing function to make sure issues are prioritised well and still have a relevant owner.

[uschi2000]

Didn't count, but it seems that it blindly closed 30+ issues without further consideration.

[iamdanfox]

@uschi2000 yeah I'm working my way through those issues in my inbox right now - the behaviour is to detect issues that have not been touched for 60days, leave a warning comment, then if there's no further attention after 7 more days, auto-close.

EDIT - I've now read through all the closed issues and re-opened ones I understand or have context on. If there are still issues that you'd prefer to keep open indefinitely, we should add a special label to grant them immortality from stalebot.

[j-baker]

I guess I'd like to understand your definition of an issue?

The way I see it, stalebot is a bot which keeps repositories clear for maintainers at the cost of hurting the experience for those that use the software.

I filed this bug because someone pointed out that it should be tracked. The only action against it so far has been a robot closing it.

The bug is still real, and internally potentially very dangerous.

[j-baker]

Like, it makes sense to me if we think it's realistic that issues actually get fixed in 60 days?

[iamdanfox]

@j-baker The intention is very much not to "hurt the experience for those that use the software".

Benefits I've seen from stalebot so far:

• it prompts us to close out already fixed issues
• it's warning comment prompted me to fix an issue (https://github.com/palantir/gradle-baseline/issues/344) that I'd filed a while ago for tracking and forgotten about.

I read through all the github notifications from stalebot's latest closing spree and re-opened bugs that seemed still valid. This specific issue is clearly one that should stay open until it's fixed because it's a valid bug. I'd actually never stumbled across this issue before so I consider it beneficial that it's been re-surfaced.

I think the big unsolved question is whether it's actually useful to keep around issues like:

• ServiceConfiguration.apiToken dropped when doing ClientConfigurations.of (https://github.com/palantir/conjure-java-runtime/issues/551) - no owner response/concrete proposal
• Re-enable deprecation logging (https://github.com/palantir/conjure-java-runtime/issues/565)
• Consolidate tests, use assertj everywhere (https://github.com/palantir/conjure-java-runtime/issues/602)

This is the first time I've tried stalebot on a larger project, so I'm not claiming that it's perfect yet (e.g. perhaps we do need to set up a special 'long-lived' label), but if it does turn out to be net negative for maintainers and users then we should absolutely switch it off.

[stale[bot]]

This issue has been automatically marked as stale because it has not been touched in the last 60 days. Please comment if you'd like to keep it open, otherwise it'll be closed in 7 days time.

[iamdanfox]

Let's keep this open