This simplifies the logic for checking the final status when creating a new backup in the backup service.
Details
Details
You can test this using my repo grpc-playground and intentionally launching only the backup service (without a blob service in another shell). Then, if you try to send a new backup, you'll see it works properly.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| services/backup/src/Reactors/server/CreateNewBackupReactor.cpp | ||
|---|---|---|
| 91 | Why it was necessary to have state == ReactorState::DONE? Why it is no longer necessary? | |
| services/backup/src/Reactors/server/CreateNewBackupReactor.cpp | ||
|---|---|---|
| 91 | It's unnecessary because we know it's done - we wait until the done callback is called. But ok, we can add a sanity check here. | |
| services/backup/src/Reactors/server/CreateNewBackupReactor.cpp | ||
|---|---|---|
| 88–91 ↗ | (On Diff #13348) | Maybe it looks odd to have two distinct consecutive ifs with the same condition but it makes sense in this case. |
| services/backup/src/Reactors/server/CreateNewBackupReactor.cpp | ||
|---|---|---|
| 88–93 ↗ | (On Diff #13348) | This pattern is really risky, but in our case it's probably fine. The main risk is due to spurious wakeup - if there are a couple of threads waiting on the same condition, it is possible that more than one will be waken up. In our case only one thread waits, so it's fine. |
| services/backup/src/Reactors/server/CreateNewBackupReactor.cpp | ||
|---|---|---|
| 88–93 ↗ | (On Diff #13348) | yeah, it's a 1v1 relation basically |