Add exponential backoff to cloud reconnect

[MazurenkoNick]

Pull Request description

Put your PR description here instead of this sentence.

General checklist

• You have reviewed the guidelines document.
• Labels that classify your pull request have been added.
• The milestone is specified and corresponds to fix version.
• Description references specific issue.
• Description contains human-readable scope of changes.
• Description contains brief notes about what needs to be added to the documentation.
• No merge conflicts, commented blocks of code, code formatting issues.
• Changes are backward compatible or upgrade script is provided.
• Similar PR is opened for PE version to simplify merge. Crosslinks between PRs added. Required for internal contributors only.

Front-End feature checklist

• Screenshots with affected component(s) are added. The best option is to provide 2 screens: before and after changes;
• If you change the widget or other API, ensure it is backward-compatible or upgrade script is present.
• Ensure new API is documented here

Back-End feature checklist

• Added corresponding unit and/or integration test(s). Provide written explanation in the PR description if you have failed to add tests.
• If new dependency was added: the dependency tree is checked for conflicts.
• If new service was added: the service is marked with corresponding @TbCoreComponent, @TbRuleEngineComponent, @TbTransportComponent, etc.
• If new REST API was added: the RestClient.java was updated, issue for Python REST client is created.
• If new yml property was added: make sure a description is added (above or near the property).

[MazurenkoNick]

Review summary

Reviewed 2 changed files in Add exponential backoff to cloud reconnect. Left 4 comment(s) inline.

The backoff logic itself reads well and the reconnecting flag + capped doubling are a clear improvement over the old fixed-rate loop. The main concerns are around the reconnectFuture state machine: it is now mutated from an additional thread without synchronization, and it is never cleared on the destroy/partition-loss path, which can leave the reconnectFuture == null guard permanently blocking a restart. There are also no tests for the new scheduling logic.

---

This review was auto-generated. Findings may contain errors — please verify before applying changes.

[MazurenkoNick]

Re-review summary

Re-reviewed Add exponential backoff to cloud reconnect — verified 4 finding(s) from previous review.

Status	Count
✅ Resolved	4
💬 Acknowledged	0

All previous findings have been addressed. Also found 2 minor quality nit(s) in the fix commit, commented inline (test naming/DRY only — nothing blocking).

Finding details

• ✅ BaseCloudManagerService.java (destroy) — reconnectFuture wasn't cleared on the destroy/partition-loss path — Fixed: destroy() now calls cancelReconnect(), which cancels and nulls the future.
• ✅ BaseCloudManagerService.java (scheduleReconnectAttempt) — reconnect state mutated across gRPC and reconnect threads without synchronization — Fixed: all state now guarded by reconnectLock; onEdgeUpdate/destroy share the cancelReconnect() helper.
• ✅ BaseCloudManagerService.java:107 — 180000 default duplicated in @Value and tb-edge.yml — Fixed: annotation default dropped, relying on the yml.
• ✅ BaseCloudManagerService.java — no tests for the backoff/state-machine logic — Fixed: BaseCloudManagerServiceTest added covering delay doubling/capping, no-op re-entry, timeout reset, and destroy cleanup.

---

This re-review was auto-generated. Findings may contain errors — please verify before applying changes.