Another open question is: before we call posix_isatty(STDOUT), how do we test whether STDOUT is a valid handle?

I believe the above changes resolved this, and it hasn't cropped up again.

I believe D21466 resolved this, since it hasn't cropped up again even though daemon runtimes between restarts have been very long at various periods in the last year.

This was resolved by D21452. PHI1880 has some unrelated additional plans.

Although I didn't look particularly hard, I can't immediately find any more evidence that this is occurring in production.

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.

Update the daemon UI to break tasks down by object/container.

See T13591. Tasks now (may) have a containerPHID, and whatever daemon console changes are made in service of dynamic generation should also expose container objects.

After D21518:

These parts seem likely resolved once I convince myself the patches so far actually work:

I have a change to add containerPHID locally, but it ends up having relatively high complexity because several other patches (including 20190909.herald.01.rebuild.php) call PhabricatorRebuildIndexesWorker::rebuildObjectsWithQuery(...), which does not work if executed in sequence prior to a worker queue schema change.

This also relates slightly to T13580, but I believe the two issues are addressable independently.

However, I'd like to have a better understanding of how we're reaching this state, and I'm not satisfied that these repositories are going down the "natural" pathway (of changing ref definitions after the import starts) and suspect there is some more complicated interaction at play here.

I'm hoping to land at least a narrow fix for this today to support an import in PHI1979 tomorrow. However, I'd like to have a better understanding of how we're reaching this state, and I'm not satisfied that these repositories are going down the "natural" pathway (of changing ref definitions after the import starts) and suspect there is some more complicated interaction at play here.

I know it's an old thread, but I am encountering what is, as far as I can tell, exactly the same issue. I'm on the latest version of trunk (~Oct 26) with php 5.5.9 on Linux 3.13.0. I also observed the issue on the May 30 version.

This synthetic script demonstrates the conceptual problem with FutureIterator:

In D21426, I removed phd.trace and phd.verbose.