Change Details

The landing page of a Diffusion repository consists of multiple components -- file browse, history, branches, etc. Occasionally an error will occur when creating the content for one of these pieces, which when it does so will cause the entire landing page content to be replaced with an error message. This can happen when e.g. deleting recent local state for a repository, causing the history view to attempt querying a non-existent commit (see also T13365). This behavior is usually expected however in the case of repositories it's very helpful to access the Manage repositories piece when these errors occur. Normally this is accessed by going to the Actions > Manage menu option from the landing page but this component becomes inaccessible if any of the other content pieces runs into an error being generated. The behavior here could be better by e.g. only showing the error information within the section content of the page that had the issue, but still loading other components which don't fail to load. --- In `DiffusionRepositoryController` the `buildNormalContent()` function makes several calls to `callConduitMethod()` which passes a `true` into `DiffusionQuery::callConduitWithDiffusionRequest()` for the `return_future` argument which results in attempting to resolve the future immediately. The error handling in `buildNormalContent()` however appears to assume that it will handle the futures being resolved via a `FutureIterator`, but then also later calls `resolve()` for each individual future inside of a try/catch (except for the one in `buildBranchList()`). The `callConduitMethod()` invocations from `buildNormalContent()` should try to be done in a way that they aren't immediately resolved outside of a try/catch, and additionally may not need to use the `FutureIterator` as it may not be convenient to resolve the futures in a try/catch through an iterator.

The landing page of a Diffusion repository consists of multiple components -- file browse, history, branches, etc. Occasionally an error will occur when creating the content for one of these pieces, which when it does so will cause the entire landing page content to be replaced with an error message. This can happen when e.g. deleting recent local state for a repository, causing the history view to attempt querying a non-existent commit (see also T13365). This behavior is usually expected however in the case of repositories it's very helpful to access the Manage repositories piece when these errors occur. Normally this is accessed by going to the Actions > Manage menu option from the landing page but this component becomes inaccessible if any of the other content pieces runs into an error being generated. The behavior here could be better by e.g. only showing the error information within the section content of the page that had the issue, but still loading other components which don't fail to load.

The landing page of a Diffusion repository consists of multiple components -- file browse, history, branches, etc. Occasionally an error will occur when creating the content for one of these pieces, which when it does so will cause the entire landing page content to be replaced with an error message. This can happen when e.g. deleting recent local state for a repository, causing the history view to attempt querying a non-existent commit (see also T13365). This behavior is usually expected however in the case of repositories it's very helpful to access the Manage repositories piece when these errors occur. Normally this is accessed by going to the Actions > Manage menu option from the landing page but this component becomes inaccessible if any of the other content pieces runs into an error being generated. The behavior here could be better by e.g. only showing the error information within the section content of the page that had the issue, but still loading other components which don't fail to load. --- In `DiffusionRepositoryController` the `buildNormalContent()` function makes several calls to `callConduitMethod()` which passes a `true` into `DiffusionQuery::callConduitWithDiffusionRequest()` for the `return_future` argument which results in attempting to resolve the future immediately. The error handling in `buildNormalContent()` however appears to assume that it will handle the futures being resolved via a `FutureIterator`, but then also later calls `resolve()` for each individual future inside of a try/catch (except for the one in `buildBranchList()`). The `callConduitMethod()` invocations from `buildNormalContent()` should try to be done in a way that they aren't immediately resolved outside of a try/catch, and additionally may not need to use the `FutureIterator` as it may not be convenient to resolve the futures in a try/catch through an iterator.