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
- Branch
- arcpatch-D4160
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| services/backup/src/Reactors/server/CreateNewBackupReactor.cpp | ||
|---|---|---|
| 91 ↗ | (On Diff #13232) | Why it was necessary to have state == ReactorState::DONE? Why it is no longer necessary? |
| services/backup/src/Reactors/server/CreateNewBackupReactor.cpp | ||
|---|---|---|
| 91 ↗ | (On Diff #13232) | 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 | 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 | 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 | yeah, it's a 1v1 relation basically | |