Page MenuHomePhabricator

Document the need to restart Phabricator after performing a restore
ClosedPublic

Authored by epriestley on Jul 3 2017, 5:27 PM.
Tags
None
Referenced Files
F14393604: D18180.id43735.diff
Sun, Dec 22, 12:19 AM
Unknown Object (File)
Wed, Dec 18, 7:43 AM
Unknown Object (File)
Sat, Dec 14, 4:19 PM
Unknown Object (File)
Wed, Dec 4, 9:47 PM
Unknown Object (File)
Sun, Dec 1, 10:59 AM
Unknown Object (File)
Nov 20 2024, 8:17 PM
Unknown Object (File)
Nov 17 2024, 7:01 AM
Unknown Object (File)
Oct 28 2024, 2:16 AM
Subscribers
None

Details

Summary

Depending on how you perform a restore, APC (or, e.g., running daemon processes) might be poisoned with out-of-date caches.

Add a note to advise installs to restart after restoring data.

See also lengthy fishing expedition support thread.

Test Plan

Read the text.

Diff Detail

Repository
rP Phabricator
Branch
restart1
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 17624
Build 23658: Run Core Tests
Build 23657: arc lint + arc unit

Event Timeline

I guess there's no way to detect that this bad state and warn the user about it explicitly?

This revision is now accepted and ready to land.Jul 3 2017, 5:36 PM

We have some code like this:

$old = ...;
$new = compute_hash($data);
if (!compare($old_hash, $new_hash)) {
 throw no;
}

We could do this:

$old = ...;
$new = compute_hash($data);
if (!equal($old_hash, $new_hash)) {
  dump_the_cache();
  $old = ...;
  $new = compute_hash($data);
  if (!equal($old_hash, $new_hash)) {
    throw no;
  }
}

...but that doesn't feel great, and there are probably 500 other places where we have similar issues.

When we write a file, we have some code like this:

$hmac_key = read_from_cache();
$integrity_hash = compute_hash($data, $hmac_key);

Unlike the read case, we have no way to tell if that key is suspect.

We could just not cache the key, or not cache it on writes, but if we start down that path we probably end up at "no caching because sometimes installs do crazy things" which is probably the wrong result.

I also can't come up with any way to detect that a restore has occurred, since you might only be rolling back a few minutes, not restoring an export / entirely different install.

So none of these approaches feel terribly satisfying, but I don't see a better way to figure this out automatically.

This revision was automatically updated to reflect the committed changes.