...possibly, but not conclusively, a result of an SSH version upgrade...
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 14 2021
Sep 5 2021
So that part is correct, but swapping the commit and branch was incidental, and I overlooked it because we usually get the same result: in common cases, this is moot because ancestors(<branch name>) is equivalent to ancestors(<heads of that branch>), and branch(<commit hash>) is equivalent to branch(<branch of that commit>). The latter is always equivalent; the former is equivalent when commit is the single head of branch, which it almost always is in regular use.
But this behavior (on this install) is unambiguously wrong:
...since b7be5c961297 (the parameter) is an ancestor of 162a9c1e8e44 (the first commit in the result set). I'll send you a diff.
Good catch!
Sep 4 2021
One tangential thing I noticed from the error messages in these cases, in DiffusionHistoryQueryConduitAPIMethod the getMercurialResult() function executes this hg command
$path_args = array(); if (strlen($path)) { $path_args[] = $path; $revset_arg = hgsprintf( 'reverse(ancestors(%s))', $commit_hash); } else { $revset_arg = hgsprintf( 'reverse(ancestors(%s)) and branch(%s)', $drequest->getBranch(), $commit_hash); }
With just the updates to the future handling this is now the landing page I see with missing commits:
Ah, that's helpful. I found a repro, it's specific to the behavior of the ImmediateFuture pathway for non-clustered resolution of Conduit "calls". This should force it from any configuration/state, I think:
I'm able to reproduce this but I'll investigate further
I'll have some more detail in D21717 in a minute, but I can't immediately reproduce this, I think? If I intentionally break diffusion.historyquery like this:
Sep 3 2021
In Mercurial, I'm not exactly sure how wide this window is. Since you normally can't strip commits in the remote by pushing (AFAIK?)
This is true, though it does change a bit if we enable evolve server-side. Then when commits/branches are pruned when pushing/pulling those obsolete markers will also be transferred, allowing similar disappearing commits (retrievable via —hidden). However I believe by default mercurial does not allow pruning public changesets (would require forcibly changing phases on client/server, or running a server/branch in non-publishing mode). Supporting evolve/topics server-side is probably large enough that it would be its own big project. So I think this assumption holds up well.
(D21715 is still a draft, but I left a couple of more specific comments there.)
Does this refer to when multiple dependent commits are pushed and then stripped from the on-disk state?
Another caveat here is that if you destroy commits directly in Phabricator's working copy in certain states, it's possible it won't be able to trace ancestry to find all the commits you destroyed in order to mark them unreachable. However, this window is narrow. For Git, you can bin/repository mark-reachable to rebuild reachability if you know you've done a bunch of dangerous mutations to the on-disk state.
Jun 1 2021
Since observed repositories version differently today, this strategy won't work -- but I can't come up with any valid reason to ever put a repository into a "write maintenance" mode anyway. I do imagine making observed repositories "replay" fetches into the push log (as though they were pushes) in the future, but that still won't make "write maintenance" on an observed repository meaningful, so it seems fine to just prevent putting non-hosted repositories into this mode.
A minor issue on the way to this is that calling synchronizeWorkingCopyBeforeWrite() with an omnipotent viewer will write to the WorkingCopyVersion table with a null userPHID, which shows as "Unknown Object" in the UI.
A useful maintenance operation for staging area repositories is to remove out-of-date staging refs: old diffs which have already landed. This is of some particular importance for large installs, since Git has a significant per-ref overhead for many operations until protocol v2: by the time a repository has ~50K refs, interacting with it in basically any way has become slow and cumbersome.
Apr 13 2021
This issue is still occurring.. the root cause is related to phabricator being set to allow-public. My fix still works and it would be nice if anyone here would support me bringing this upstream.
Mar 28 2021
One call to for-each-ref comes from resolving a list of commit hashes, to test if they still exist. This is accomplished with DiffusionLowLevelResolveRefsQuery, which calls git for-each-ref first and falls back to git cat-file --batch-check.
Has this repository changed?
Mar 26 2021
Mar 17 2021
A general concern with "batch processing" is that it's quite bad if one commit failing to import can stall the entire repository forever.
See also T13552, which modifies the above discussion. The "Update" steps now happen after the "Publish" step.
When you are viewing a document with engine X, and comments originally made with engine Y are present, this should be indicated ("This comment was made while looking at this change as a Q document."). They should probably also be moved to the top/bottom of the file, at least by default, since "Jupyter line number 9 = raw source line number 9" is an exceptionally bad and confusing guess at how to map line numbers.
Mar 15 2021
Mar 12 2021
For now, I fixed the explicit misinformation in audit.can-author-close-audit, at least.
Mar 11 2021
Mar 10 2021
Although I didn't look particularly hard, I can't immediately find any more evidence that this is occurring in production.
One remaining artifact here is this configuration option:
Mar 9 2021
Long ago, we used to write a <package, commit> audit relationship with "AUDIT_NOT_REQUIRED", meaning "This commit affects the package, but package owners don't need to audit it.".
PhabricatorAuditStatusConstants appears to have a set of unused constants:
Mar 4 2021
Evidence increasingly suggests that the root problem here was GET_LOCK() issue in T13627, not an error in an sshd subprocess context.
Mar 2 2021
In general, Phacility production hosts may interact with logs as several different users:
This ran into some filesystem permissions issues and needs followup.
Mar 1 2021
When we are importing a commit, we often don't have any legitimate user to act as: the commit may come from an observed repository (so we never authenticated a pusher), and the "Author" and "Committer" strings are arbitrary and untrusted in Git and Mercurial.
All three of these are almost certainly diffusion.rawdiffquery, I think the first one just predated D21463 reaching production so it didn't show the method.
This deployed, and appears resolved.
Feb 27 2021
Feb 26 2021
Feb 25 2021
This is a brute force approach to support "context blocks" without taking any steps backwards (i.e., it supports older transactions and newer, modular transactions), but it feels like this is a lot of steps sideways and this change would be far better if it took a nuanced approach through T12921.
D21574 implements the hovercard and summary length changes.
Feb 24 2021
Feb 19 2021
Feb 18 2021
Feb 15 2021
See PHI1997, which discusses things from the perspective of reporting coverage from a build system.
Feb 4 2021
This more-or-less worked as desired. Some minor issues:
Feb 2 2021
Update the daemon UI to break tasks down by object/container.
The affected user in PHI1980 reported that this appeared to be effective in resolving the issue.