Page MenuHomePhabricator

[services] Backup - Send Log - Use separate variables for value and blob holder
ClosedPublic

Authored by karol on Jun 30 2022, 3:47 AM.
Tags
None
Referenced Files
F2214423: D4411.id14083.diff
Mon, Jul 8, 4:31 PM
F2213523: D4411.id14147.diff
Mon, Jul 8, 1:28 PM
F2213486: D4411.diff
Mon, Jul 8, 1:15 PM
Unknown Object (File)
Sat, Jul 6, 4:45 PM
Unknown Object (File)
Wed, Jul 3, 7:14 AM
Unknown Object (File)
Mon, Jul 1, 3:16 AM
Unknown Object (File)
Sat, Jun 29, 3:04 AM
Unknown Object (File)
Fri, Jun 28, 11:45 AM

Details

Summary

Depends on D4321

We want to use separate variables for the blob hash and value instead of just one variable value

Test Plan

Services build, for now this went out of sync with the integration tests

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

unrelated keyserver build hangs

services/backup/src/Reactors/server/SendLogReactor.cpp
19–20 ↗(On Diff #14025)

Note – the discussion about ternary initially started here, but that diff was split and now the code is here

tomek requested changes to this revision.Jun 30 2022, 9:10 AM
tomek added inline comments.
services/backup/src/Reactors/server/SendLogReactor.cpp
19–20 ↗(On Diff #14025)

As I suggested in D4321, we can

consider assigning this->persistenceMethod == PersistenceMethod::BLOB to a variable - it is used twice and having a variable with shorter name would allow keeping the ternary

93–94 ↗(On Diff #14025)

I'm not sure how closely the new approach should match the old one, but for example this->initializePutReactor(); call is missing. Is it intentional?

This revision now requires changes to proceed.Jun 30 2022, 9:10 AM
services/backup/src/Reactors/server/SendLogReactor.cpp
15–22 ↗(On Diff #14025)

Ok, so let's go with another suggestion based on what Tomek said to avoid empty cycles.

Now, there are 2 suggestions, among which the first isn't good in my opinion. So can we leave this as is or maybe do it as Tomek suggested?

If none of them works for you, then I'm out of ideas. This is such a simple case that it's even hard to come up with yet another alternative.

19–20 ↗(On Diff #14025)

Continuing the discussion from the other diff:

As for the best alternative... I am not sure about that. I don't feel that strongly about this case honestly, but I'm sure there is some alternative if you look into it. I don't have the time right now to do that research... in general, the expectation is that the diff author does research in response to requests from diff reviewers.

Please, read my comment from that diff:

Honestly, I thought about this and do not see a decent replacement. What is an alternative here?

string str = this->value;
if (this->persistenceMethod == PersistenceMethod::BLOB) this->blobHolder;

This causes re-assignment, which is more expensive and less readable for me. The ternary is pretty straight and clear. If you have any good suggestions, please let me know.

Here I added an alternative ^

in general, the expectation is that the diff author does research in response to requests from diff reviewers.

I did it above. You didn't refer to my suggestion.

93–94 ↗(On Diff #14025)

It's ok, this if here stands for the continuation of the put operation that already has begun. For safety (to avoid possible crashes if the logic failed for some reason) we can add a check here, will do (I mean we can throw if the put reactor is null).

karol edited the summary of this revision. (Show Details)
karol edited the test plan for this revision. (Show Details)

add sanity check for put reactor null

services/backup/src/Reactors/server/SendLogReactor.cpp
15–22 ↗(On Diff #14025)

@palys-swm's suggestion looks great! It's a simple solution that fits the rules listed here

tomek requested changes to this revision.Jul 4 2022, 3:21 AM
tomek added inline comments.
services/backup/src/Reactors/server/SendLogReactor.cpp
15–22 ↗(On Diff #14025)

Ok, so it looks like we have an agreement - back to your queue @karol-bisztyga

This revision now requires changes to proceed.Jul 4 2022, 3:21 AM
This revision is now accepted and ready to land.Jul 7 2022, 3:43 AM
This revision was landed with ongoing or failed builds.Jul 8 2022, 2:30 AM
This revision was automatically updated to reflect the committed changes.