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.
Differential D18180
Document the need to restart Phabricator after performing a restore epriestley on Jul 3 2017, 5:27 PM. Authored by Tags None Referenced Files
Subscribers None
Details 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. Read the text.
Diff Detail
Event TimelineComment Actions I guess there's no way to detect that this bad state and warn the user about it explicitly? Comment Actions 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. |