Fix HTTP compressors finalization#58846
Conversation
|
This is an automated comment for commit d5d060a with description of existing statuses. It's updated for the latest CI running ❌ Click here to open a full report in a separate page Successful checks
|
|
Please add a test. PS. It does not seem right to call finalize in destructor. The ideal flow is when you call finalize explicitly before destructing, or if you didn't, the destructor ignores the data. But this change is also ok for me. |
|
I agree with @antonio2368 I think it's better to find where buffers should call |
You are understand right what would happen. That could lead to data loss.
I don't think that it could ever be ok. |
|
@CheSema I would argue that it's not always practical to not utilize destructor for the exact purpose destructor exists - for example if we use temporary object or some cases of exception processing. Data loss is rather signifier of incorrect objects' ownership, lack of proper objects' initialization and similar issues. Though I agree that in this particular case it's better to add explicit finalization, overall if we have a case when finalization in destructor leads to data loss or data corruption - there is a deeper problem worth of investigation and proper fix. |
I don't wont to argue here at all. There is a deep problem -- we use buffers API to write a file. All such tasks/conversations are the consequences of that problem. |
It's not muted - it's reported in catch. I understand the concern of having finalize in destructor can encourage ppl to neglect explicit finalization, but maybe it shouldn't outweigh the usefulness of this... |
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Fix HTTP compressors. Follow-up #58475
Manifests as error when HTTP request includes
compress=1&enable_http_compression=1along with HTTP headerAccept-Encoding: