Engineer(s): Valentin Kovalenko, Slav Babanin 2026-Jul-03: Timeline updates "Cost to Date" was changed from 23.5 to 25.5. "Final Cost Estimate" was changed from 25.5 to 25.5 + 7.5 = 33. "End date" was changed from 2026-Jul-03 to 2026-Sep-04 (this date includes a 1-week buffer). "Confidence Status" set to "Yellow". What was accomplished since the last update? Finished drafting code for the refactorings / internal driver functionality known to be needed to start implementing the overload retry policy itself. These changes are in review. What's the focus over the next two weeks? Move through review and merge the aforementioned changes. Start implementing the overload retry policy itself. Any risks/blockers/impediments? Valentin would like to take 3 weeks of PTO somwehere in Aug/Sep, Slava, I believe, is planning 1 week of PTO in Aug. The "End date" was set ignoring these risks for now. Even if someone else replaces one/both of us, that introduces additional delays and, likely, blocking dependencies. Valentin still thinks that Slava is stretched too thing between the telemetry project, the Hibernate project and the backpressure project. Notes What was accomplished since the last update? Valentin Kovalenko Walked the reviewier, Slava, through all the changes in the PR Introduce the RetryPolicy abstraction #2004 . Started and finished working on Introduce necessary executors and implement sleepAsync . The preview PR Introduce necessary executors and implement sleepAsync #3 turned out non-trivial. Went through AI review, addressed concerns. The details are in the description of the arofementioned preview PR. The actual PR will be created when Introduce the RetryPolicy abstraction #2004 survives review and is merged. Slav Babanin Walked with me through the changes in the PR Introduce the RetryPolicy abstraction #2004 . Gave his initial thoughts, which I made into PR comments. What's the focus over the next two weeks? Valentin Kovalenko Address review concerns in the PR Introduce the RetryPolicy abstraction #2004 . Continue working according to the implementation plan . Items 3, 4, 5 are the most important. Slav Babanin Review the PR Introduce the RetryPolicy abstraction #2004 . Review the PR for Introduce necessary executors and implement sleepAsync .

2026-07-06 - 🟡 Potential Risk Engineer(s): Valentin Kovalenko, Slav Babanin 2026-Jul-03: Timeline updates "Cost to Date" was changed from 23.5 to 25.5. "Final Cost Estimate" was changed from 25.5 to 25.5 + 7.5 = 33. "End date" was changed from 2026-Jul-03 to 2026-Sep-04 (this date includes a 1-week buffer). "Confidence Status" set to "Yellow". What was accomplished since the last update? Finished drafting code for the refactorings / internal driver functionality known to be needed to start implementing the overload retry policy itself. These changes are in review. What's the focus over the next two weeks? Move through review and merge the aforementioned changes. Start implementing the overload retry policy itself. Any risks/blockers/impediments? Valentin would like to take 3 weeks of PTO somwehere in Aug/Sep, Slava, I believe, is planning 1 week of PTO in Aug. The "End date" was set ignoring these risks for now. Even if someone else replaces one/both of us, that introduces additional delays and, likely, blocking dependencies. Valentin still thinks that Slava is stretched too thing between the telemetry project, the Hibernate project and the backpressure project. Notes What was accomplished since the last update? Valentin Kovalenko Walked the reviewier, Slava, through all the changes in the PR Introduce the RetryPolicy abstraction #2004 . Started and finished working on Introduce necessary executors and implement sleepAsync . The preview PR Introduce necessary executors and implement sleepAsync #3 turned out non-trivial. Went through AI review, addressed concerns. The details are in the description of the arofementioned preview PR. The actual PR will be created when Introduce the RetryPolicy abstraction #2004 survives review and is merged. Slav Babanin Walked with me through the changes in the PR Introduce the RetryPolicy abstraction #2004 . Gave his initial thoughts, which I made into PR comments. What's the focus over the next two weeks? Valentin Kovalenko Address review concerns in the PR Introduce the RetryPolicy abstraction #2004 . Continue working according to the implementation plan . Items 3, 4, 5 are the most important. Slav Babanin Review the PR Introduce the RetryPolicy abstraction #2004 . Review the PR for Introduce necessary executors and implement sleepAsync . 2026-06-22 - 🔴 Roadblock Engineer(s): Valentin Kovalenko, Slav Babanin 2026-Jun-19: Timeline updates "Cost to Date" was changed from 21.5 to 23.5: 1.5 weeks for Valentin Kovalenko (I took 2 days off and spent a less than a day reviewing "Scope: Periodic Client Telemetry", which I haven't finished), 0.5 weeks for Slav Babanin. "Confidence Status" set to "Red". We have 2 estimated weeks left, in which we have to do the code walkthrough and review for the PR Introduce the RetryPolicy abstraction #2004 , and implement at least items 3, 4, 5 from the implementation plan , which are estimated for 11 days (more than 2 weeks). I also will still have to finish reviewing "Scope: Periodic Client Telemetry". Since we can't cut scope by not doing any of the items 3, 4, 5, we will have to increase "Final Cost Estimate" in the next bi-weekly report. What was accomplished since the last update? Valentin Kovalenko Moved through review and merged the PR Refactor MixedBulkWriteOperation to simplify retry logic there #1989 . Finished working on and created the PR Introduce the RetryPolicy abstraction #2004 . Went through AI review, addressed concerns. Slav Babanin Reviewed the PR Refactor MixedBulkWriteOperation to simplify retry logic there #1989 . What's the focus over the next two weeks? Valentin Kovalenko Do a detailed code walkthrough for the reviewer, Slava: PR Introduce the RetryPolicy abstraction #2004 . Continue working according to the implementation plan . Items 3, 4, 5 are the most important. Slav Babanin Review PR Introduce the RetryPolicy abstraction #2004 . Review other backpressure PRs as needed. Though it is almost guaranteed that at most Slava will be able to review is the aforementioned PR. Any risks/blockers/impediments? Nothing. Notes Nothing. 2026-06-08 - 🟡 Potential Risk Engineer(s): Valentin Kovalenko, Slav Babanin 2026-Jun-05: Timeline updates "Cost to Date" was changed from 19.5 to 21.5: 2 weeks for Valentin Kovalenko (mostly) and Slav Babanin. "Confidence Status" set to "Yellow". We have 4 estimated weeks left, with refactoring not having been completed, and the rest, non-refactoring work, having been estimated at 4.5 weeks (note that "the rest" is dictated by the spec, which we know is going to be changed, but we don't know how/when). The estimate for refactoring needed to be more aggressive. We are required to provide a path to "Green", but the only one I can see is to increase the "Final Cost Estimate". I'll discuss this with the team and the manager. What was accomplished since the last update? Valentin Kovalenko Finished refactoring the async part of MixedBulkWriteOperation , created Refactor MixedBulkWriteOperation to simplify retry logic there #1989 . Did a detailed code walkthrough with the reviewer, Slav Babanin, addressed concerns raised in the process. The PR is now in review. There appeared new failures in Client Backpressure . Rebased `backpressure` on top of `main`. Left a comment on a new test that still needs a fix. Continued working on Introduce the RetryPolicy abstraction . What's the focus over the next two weeks? Valentin Kovalenko Finish working on and create a PR for Introduce the RetryPolicy abstraction . Slav Babanin Review backpressure PRs as needed. Any risks/blockers/impediments? Nothing. Notes Nothing. 2026-05-25 - 🟢 On Track Engineer(s): Valentin Kovalenko, Slav Babanin 2026-May-22: Timeline updates "Cost to Date" was changed from 17.5 to 19.5: 2 weeks for Valentin Kovalenko, 0 weeks for Slav Babanin. "Confidence Status" set to "Green". In the last two weeks it has been discovered that the proposed plan needed a change, increasing the amount of work. However, since we also learned we are not going to implement the overload retry policy business logic for now, we left the "Final Cost Estimate" and "End date" unchanged. What was accomplished since the last update? Valentin Kovalenko Refactored retries to introduce the RetryPolcity abstraction. This change is local, in draft, and needs work before a PR can be created. Refactored the synchronous half of MixedBulkWriteOperation so that the aforementioned RetryPolcity abstraction could be used in this operation without requiring us to implement a custom policy that reimplements all the busineess logic. What's the focus over the next two weeks? Valentin Kovalenko Refactor the asynchronous half of MixedBulkWriteOperation . Create a PR. Work on finishing up refactoring that introduces the RetryPolcity abstraction. Slav Babanin Review backpressure PRs as needed. Any risks/blockers/impediments? Nothing. Notes Nothing. 2026-03-02 - 🔴 Roadblock Engineer(s): Valentin Kovalenko, Slav Babanin 2026-01-12: Timeline updates The "End date", "Final Cost Estimate" updating instructions are unclear, especially for the "Final Cost Estimate" ( https://wiki.corp.mongodb.com/spaces/DRIVERS/pages/214438893/DBX+Bi-Weekly+Project+Updates+Process#DBXBiWeeklyProjectUpdatesProcess-FieldstoUpdate ). Also, those instructions refer to "current estimates", "projected final cost", "target end date" - there are no such fields. There are "Scope Cost Estimate", "Final Cost Estimate", "Target end", "End date" fields, and it is unclear which of these are meant above, if any. It would have been helpful if the instructions referred to the fields by their exact names, and used formatting that allows readers to distinguish field names from the rest of the text. It may be a good idea to name all the fields such that the names help to understand the meaning, and also are consistent with each other. The "Confidence Status" updating instruction "Confidence status is to be applied against the date reported in the End date field." seems incorrect: The "End date" is allowed to change as the project progresses, to reflect the date by which we estimate to complete the project. Therefore, the instruction quoted above means that the "Confidence Status" should always be green, which is certainly not what the instruction is supposed to convey. What was accomplished since the last update? Valentin Kovalenko: Finished reviewing DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors #1862 . Re-reviewed JAVA-5950: Update Transactions Convenient API with exponential backoff on retries #1852 . Partially reviewed JAVA-6021, JAVA-6074: Add support for server selection's deprioritized servers to all topologies. #1860 . Slav Babanin: Added unified tests to JAVA-6021, JAVA-6074: Add support for server selection's deprioritized servers to all topologies. #1860 . Reviewed DRIVERS-3391: Clarify withTransaction CSOT timeout error with backoff+jitter #1890 . What's the focus over the next two weeks? One of the two next weeks (the second one) I am the first responder. Finish reviewing JAVA-6021, JAVA-6074: Add support for server selection's deprioritized servers to all topologies. #1860 . Re-review JAVA-5950: Update Transactions Convenient API with exponential backoff on retries #1852 . Re-review DRIVERS-3391: Clarify withTransaction CSOT timeout error with backoff+jitter #1890 . Continue reviewing other relevant PRs as needed. No implementation work is expected. Any risks/blockers/impediments? No. 2026-02-18 - 🔴 Roadblock Engineer(s): Valentin Kovalenko, Slav Babanin 2026-01-29: Timeline updates "Target end", "Scope Cost Estimate" will be updated again after discussing with the team. What was accomplished since the last update? Valentin Kovalenko: Continued reviewing DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors . Three leads, the PR author and I have been having regular meetings. I believe, we are getting closer to a state at which I will be able to approve the requirements expressed in the PR. Re-reviewed PR [JAVA-5950 Update Transactions Convenient API with exponential backoff on retries] ( https://github.com/mongodb/mongo-java-driver/pull/1852 ). Slav Babanin: Worked on JAVA-6021: Add support for server selection's deprioritized servers to all topologies . Added additional test cases and addressed merge conflicts. What's the focus over the next two weeks? Continue reviewing DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors , hopefully approve. If DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors is done and ready to be implemented, continue working on JAVA-6025: Client Backpressure: design overload retry policy concurrently with JAVA-5956: Exponential backoff and jitter in retry loops . Work on JAVA-6021: Add support for server selection's deprioritized servers to all topologies . Resolve new merge conflicts and incorporate spec test changes. Continue reviewing the existing JAVA PRs done as part of JAVA-5942: Client Backpressure , JAVA-6019: Client Backpressure: overload retry policy as needed. Any risks/blockers/impediments? No. 2026-02-03 - 🔴 Roadblock Engineer(s): Valentin Kovalenko, Slav Babanin 2026-01-29: Timeline updates "Target end", "Scope Cost Estimate" will be updated again after discussing with the team. What was accomplished since the last update? Valentin Kovalenko: Continued reviewing DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors . Three leads, the PR author and I have been having regular meetings. I believe, we are getting closer to a state at which I will be able to approve the requirements expressed in the PR. Re-reviewed PR [JAVA-5950 Update Transactions Convenient API with exponential backoff on retries] ( https://github.com/mongodb/mongo-java-driver/pull/1852 ). Slav Babanin: Worked on JAVA-6021: Add support for server selection's deprioritized servers to all topologies . Added additional test cases and addressed merge conflicts. What's the focus over the next two weeks? Continue reviewing DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors , hopefully approve. If DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors is done and ready to be implemented, continue working on JAVA-6025: Client Backpressure: design overload retry policy concurrently with JAVA-5956: Exponential backoff and jitter in retry loops . Work on JAVA-6021: Add support for server selection's deprioritized servers to all topologies . Resolve new merge conflicts and incorporate spec test changes. Continue reviewing the existing JAVA PRs done as part of JAVA-5942: Client Backpressure , JAVA-6019: Client Backpressure: overload retry policy as needed. Any risks/blockers/impediments? No. 2026-02-03 - No confidence status provided Engineer(s): Valentin Kovalenko, Slav Babanin 2026-01-29: Timeline updates "Target end", "Scope Cost Estimate" will be updated again after discussing with the team. What was accomplished since the last update? Valentin Kovalenko: Continued reviewing DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors . Three leads, the PR author and I have been having regular meetings. I believe, we are getting closer to a state at which I will be able to approve the requirements expressed in the PR. Re-reviewed PR [JAVA-5950 Update Transactions Convenient API with exponential backoff on retries] ( https://github.com/mongodb/mongo-java-driver/pull/1852 ). Slav Babanin: Worked on JAVA-6021: Add support for server selection's deprioritized servers to all topologies . Added additional test cases and addressed merge conflicts. What's the focus over the next two weeks? Continue reviewing DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors , hopefully approve. If DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors is done and ready to be implemented, continue working on JAVA-6025: Client Backpressure: design overload retry policy concurrently with JAVA-5956: Exponential backoff and jitter in retry loops . Work on JAVA-6021: Add support for server selection's deprioritized servers to all topologies . Resolve new merge conflicts and incorporate spec test changes. Continue reviewing the existing JAVA PRs done as part of JAVA-5942: Client Backpressure , JAVA-6019: Client Backpressure: overload retry policy as needed. Any risks/blockers/impediments? No. 2026-02-01 - No confidence status provided Engineer(s): Valentin Kovalenko, Slav Babanin 2026-01-29: Timeline updates "Target end", "Scope Cost Estimate" will be updated again after discussing with the team. What was accomplished since the last update? Valentin Kovalenko: Continued reviewing DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors . Three leads, the PR author and I have been having regular meetings. I believe, we are getting closer to a state at which I will be able to approve the requirements expressed in the PR. Re-reviewed PR [JAVA-5950 Update Transactions Convenient API with exponential backoff on retries] ( https://github.com/mongodb/mongo-java-driver/pull/1852 ). Slav Babanin: Worked on JAVA-6021: Add support for server selection's deprioritized servers to all topologies . Added additional test cases and addressed merge conflicts. What's the focus over the next two weeks? Continue reviewing DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors , hopefully approve. If DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors is done and ready to be implemented, continue working on JAVA-6025: Client Backpressure: design overload retry policy concurrently with JAVA-5956: Exponential backoff and jitter in retry loops . Work on JAVA-6021: Add support for server selection's deprioritized servers to all topologies . Resolve new merge conflicts and incorporate spec test changes. Continue reviewing the existing JAVA PRs done as part of JAVA-5942: Client Backpressure , JAVA-6019: Client Backpressure: overload retry policy as needed. Any risks/blockers/impediments? No. 2026-01-07 - No confidence status provided Engineer(s): Valentin Kovalenko 2026-01-01: "End date", "Final Cost Estimate" will be updated some time later after re-evaluating them with the team. Timeline updates See above. What was accomplished since the last update? Continued reviewing DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors . The PR has been actively updated. Reviewed the existing non-draft JAVA PRs done as part of Client Backpressure . JAVA-5950 Update Transactions Convenient API with exponential backoff on retries [JAVA-6033] ServerHeartbeatSucceededEvent is not fired for initial POLL monitoring #1856 What's the focus over the next two weeks? Continue reviewing DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors . Continue reviewing the existing JAVA PRs done as part of Client Backpressure as needed. Finish JAVA-6025: Client Backpressure: design overload retry policy , provided that the relevant spec requirements are approved, merged, and there is enough time left within the two weeks to finish the design. Any risks/blockers/impediments? The new estimates will be higher than our original estimates, both because of the scope changes and because of the changes in our understanding (though the latter can be seen a subset of the former). The new estimates are likely to be done without having the specification work completed, let alone having the Java driver design for the overload retry policy completed. 2026-01-07 - No confidence status provided Engineer(s): Valentin Kovalenko 2026-01-01: "End date", "Final Cost Estimate" will be updated some time later after re-evaluating them with the team. Timeline updates See above. What was accomplished since the last update? Continued reviewing DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors . The PR has been actively updated. Reviewed the existing non-draft JAVA PRs done as part of Client Backpressure . JAVA-5950 Update Transactions Convenient API with exponential backoff on retries [JAVA-6033] ServerHeartbeatSucceededEvent is not fired for initial POLL monitoring #1856 What's the focus over the next two weeks? Continue reviewing DRIVERS-3239: Add exponential backoff to operation retry loop for server overloaded errors . Continue reviewing the existing JAVA PRs done as part of Client Backpressure as needed. Finish JAVA-6025: Client Backpressure: design overload retry policy , provided that the relevant spec requirements are approved, merged, and there is enough time left within the two weeks to finish the design. Any risks/blockers/impediments? The new estimates will be higher than our original estimates, both because of the scope changes and because of the changes in our understanding (though the latter can be seen a subset of the former). The new estimates are likely to be done without having the specification work completed, let alone having the Java driver design for the overload retry policy completed.