xref: /aosp_15_r20/external/aws-sdk-java-v2/docs/design/core/sdk-core/sync/RequestBody/DecisionLog.md (revision 8a52c7834d808308836a99fc2a6e0ed8db339086)
1# Decision Log for SDK V2 RequestBody Content-Length
2
3## Log Entry Template
4
5**Source:** (Meeting/aside/pair programming discussion/daily standup) to (discuss/implement) X
6
7**Attendees:** Anna-Karin, Dongie, Nico, John, Zoe
8
9**Closed Decisions:**
10
111. Question? Decision. Justification.
12
13**Open Decisions:**
14
151. (Old/Reopened/New) Question?
16
17## 4/8/2021
18
19**Source:** Meeting to discuss how to address the deprecated content-length getter after adding a new `Optional<Long>` getter in sync RequestBody: https://github.com/aws/aws-sdk-java-v2/blob/master/core/sdk-core/src/main/java/software/amazon/awssdk/core/sync/RequestBody.java#L66-L71
20
21**Attendees:** Anna-Karin, Dongie, Nico, John, Zoe
22
23**Closed Decisions:**
24
251. Should we replace the old content-length getter with a new optional getter? No, because that's going to be a breaking change, adding a Deprecated annotation is more acceptable.
262. Should we use a negative value to denote the null content-length? Yes, because a negative value can be distinguished from normal zero content-length.
273. Should we throw an exception in the deprecated getter when the content-length is negative? Yes, because with an exception the customers using this deprecated method would be notified that this method is deprecated and start to use the `Optional<Long>` getter. On the other hand, since the content-length was always greater or equal to zero before this change, throwing an exception here wouldn't break any existed customers.
28
29**Open Decisions:**
30
31None
32