)]}'
{"cinder/volume/drivers/pure.py":[{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"bb8b86124bff19769110cc7f12332d9e38a4b66c","unresolved":true,"context_lines":[{"line_number":2127,"context_line":"            # volumes on the original primary are stale because async"},{"line_number":2128,"context_line":"            # replication is not bi-directional, so they are reported as"},{"line_number":2129,"context_line":"            # errored pending an admin resync."},{"line_number":2130,"context_line":"            current_array.patch_protection_groups("},{"line_number":2131,"context_line":"                names\u003d[pgroup_name],"},{"line_number":2132,"context_line":"                protection_group\u003dflasharray.ProtectionGroup("},{"line_number":2133,"context_line":"                    replication_schedule\u003dflasharray.ReplicationSchedule("}],"source_content_type":"text/x-python","patch_set":1,"id":"88e8cbd0_31cd17fb","line":2130,"updated":"2026-07-24 18:55:27.000000000","message":"In this async failback path, patch_protection_groups is called to re-enable the replication schedule but the return value is not checked. If the call fails, the method still returns replication_status: ENABLED, which could be misleading.\n\nCompare with enable_replication (line 2042) which checks res.status_code !\u003d 200 and returns ERROR on failure. The failback path should be consistent.","commit_id":"b95347fcd04754884e2e500b33296ee2387717bf"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"fff13f6038d8d070c25f32e78f1dacbbd827c6b2","unresolved":false,"context_lines":[{"line_number":2127,"context_line":"            # volumes on the original primary are stale because async"},{"line_number":2128,"context_line":"            # replication is not bi-directional, so they are reported as"},{"line_number":2129,"context_line":"            # errored pending an admin resync."},{"line_number":2130,"context_line":"            current_array.patch_protection_groups("},{"line_number":2131,"context_line":"                names\u003d[pgroup_name],"},{"line_number":2132,"context_line":"                protection_group\u003dflasharray.ProtectionGroup("},{"line_number":2133,"context_line":"                    replication_schedule\u003dflasharray.ReplicationSchedule("}],"source_content_type":"text/x-python","patch_set":1,"id":"b0e03b97_3a282a3d","line":2130,"updated":"2026-07-24 18:45:27.000000000","message":"In this async failback path, patch_protection_groups is called to re-enable the replication schedule but the return value is not checked. If the call fails, the method still returns replication_status: ENABLED, which could be misleading.\n\nCompare with enable_replication (line 2042) which checks res.status_code !\u003d 200 and returns ERROR on failure. The failback path should be consistent.","commit_id":"b95347fcd04754884e2e500b33296ee2387717bf"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"bb8b86124bff19769110cc7f12332d9e38a4b66c","unresolved":true,"context_lines":[{"line_number":2145,"context_line":"            # ActiveCluster volumes already exist and are live on the"},{"line_number":2146,"context_line":"            # secondary array via the stretched pod, so failover only needs to"},{"line_number":2147,"context_line":"            # update status - the same logic used for host failover."},{"line_number":2148,"context_line":"            secondary_array \u003d self._find_sync_failover_target()"},{"line_number":2149,"context_line":"            if not secondary_array:"},{"line_number":2150,"context_line":"                raise PureDriverException("},{"line_number":2151,"context_line":"                    reason\u003d_(\"Unable to find viable ActiveCluster secondary \""}],"source_content_type":"text/x-python","patch_set":1,"id":"754c47d7_39bc54a1","line":2148,"updated":"2026-07-24 18:55:27.000000000","message":"When is_sync\u003dTrue and secondary_backend_id is provided (not \"default\"), _find_sync_failover_target() does its own auto-discovery, silently ignoring the user-specified secondary_backend_id. In contrast, the async path at line 2157 respects it via _get_secondary().\n\nThis matches how failover_host works (sync always auto-discovers), so it may be intentional. If so, consider adding a LOG.debug noting that secondary_backend_id is ignored for ActiveCluster groups, to avoid operator confusion.","commit_id":"b95347fcd04754884e2e500b33296ee2387717bf"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"fff13f6038d8d070c25f32e78f1dacbbd827c6b2","unresolved":false,"context_lines":[{"line_number":2145,"context_line":"            # ActiveCluster volumes already exist and are live on the"},{"line_number":2146,"context_line":"            # secondary array via the stretched pod, so failover only needs to"},{"line_number":2147,"context_line":"            # update status - the same logic used for host failover."},{"line_number":2148,"context_line":"            secondary_array \u003d self._find_sync_failover_target()"},{"line_number":2149,"context_line":"            if not secondary_array:"},{"line_number":2150,"context_line":"                raise PureDriverException("},{"line_number":2151,"context_line":"                    reason\u003d_(\"Unable to find viable ActiveCluster secondary \""}],"source_content_type":"text/x-python","patch_set":1,"id":"baf04020_6e521438","line":2148,"updated":"2026-07-24 18:45:27.000000000","message":"When is_sync\u003dTrue and secondary_backend_id is provided (not \"default\"), _find_sync_failover_target() does its own auto-discovery, silently ignoring the user-specified secondary_backend_id. In contrast, the async path at line 2157 respects it via _get_secondary().\n\nThis matches how failover_host works (sync always auto-discovers), so it may be intentional. If so, consider adding a LOG.debug noting that secondary_backend_id is ignored for ActiveCluster groups, to avoid operator confusion.","commit_id":"b95347fcd04754884e2e500b33296ee2387717bf"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"bb8b86124bff19769110cc7f12332d9e38a4b66c","unresolved":true,"context_lines":[{"line_number":2158,"context_line":"            else:"},{"line_number":2159,"context_line":"                secondary_array \u003d None"},{"line_number":2160,"context_line":"                for array in self._replication_target_arrays:"},{"line_number":2161,"context_line":"                    if array.replication_type \u003d\u003d REPLICATION_TYPE_ASYNC:"},{"line_number":2162,"context_line":"                        secondary_array \u003d array"},{"line_number":2163,"context_line":"                        break"},{"line_number":2164,"context_line":"            if not secondary_array:"}],"source_content_type":"text/x-python","patch_set":1,"id":"545d014b_4affce29","line":2161,"updated":"2026-07-24 18:55:27.000000000","message":"When secondary_backend_id is not provided (it\u0027s optional per the API schema) and the group is trisync, is_sync is False (because REPLICATION_TYPE_SYNC not in {\u0027trisync\u0027}), so the code falls through to the else branch here. This loop only matches REPLICATION_TYPE_ASYNC, so a trisync target (array.replication_type \u003d\u003d REPLICATION_TYPE_TRISYNC) is never matched — secondary_array stays None and the method raises PureDriverException.\n\nFailover with an explicit secondary_backend_id works fine (goes through _get_secondary() which matches on backend_id regardless of type), but the auto-discovery path is broken for trisync groups.\n\nSuggested fix:\n\n  if array.replication_type in [REPLICATION_TYPE_ASYNC,\n                                REPLICATION_TYPE_TRISYNC]:\n\nNote: the existing _find_async_failover_target() in failover_host has the same ASYNC-only filter — that may also be a pre-existing gap, but it\u0027s out of scope for this patch.","commit_id":"b95347fcd04754884e2e500b33296ee2387717bf"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"fff13f6038d8d070c25f32e78f1dacbbd827c6b2","unresolved":false,"context_lines":[{"line_number":2158,"context_line":"            else:"},{"line_number":2159,"context_line":"                secondary_array \u003d None"},{"line_number":2160,"context_line":"                for array in self._replication_target_arrays:"},{"line_number":2161,"context_line":"                    if array.replication_type \u003d\u003d REPLICATION_TYPE_ASYNC:"},{"line_number":2162,"context_line":"                        secondary_array \u003d array"},{"line_number":2163,"context_line":"                        break"},{"line_number":2164,"context_line":"            if not secondary_array:"}],"source_content_type":"text/x-python","patch_set":1,"id":"8c3e4073_e5b8389f","line":2161,"updated":"2026-07-24 18:45:27.000000000","message":"When secondary_backend_id is not provided (it\u0027s optional per the API schema) and the group is trisync, is_sync is False (because REPLICATION_TYPE_SYNC not in {\u0027trisync\u0027}), so the code falls through to the else branch here. This loop only matches REPLICATION_TYPE_ASYNC, so a trisync target (array.replication_type \u003d\u003d REPLICATION_TYPE_TRISYNC) is never matched — secondary_array stays None and the method raises PureDriverException.\n\nFailover with an explicit secondary_backend_id works fine (goes through _get_secondary() which matches on backend_id regardless of type), but the auto-discovery path is broken for trisync groups.\n\nSuggested fix:\n\n  if array.replication_type in [REPLICATION_TYPE_ASYNC,\n                                REPLICATION_TYPE_TRISYNC]:\n\nNote: the existing _find_async_failover_target() in failover_host has the same ASYNC-only filter — that may also be a pre-existing gap, but it\u0027s out of scope for this patch.","commit_id":"b95347fcd04754884e2e500b33296ee2387717bf"}]}