Page MenuHomePhabricator

Cannot create Almanac Service Blueprint in Drydock
Closed, InvalidPublic

Description

Since the replacement of using Almanac devices instead of the Drydock hosts implementation, it seems you cannot create the replacement blueprint any more. You get this (sadly truncated) stack trace:

12015/09/23 13:15:05 [error] 627#0: *12473 FastCGI sent in stderr: "PHP message: [2015-09-23 13:15:05] EXCEPTION: (PhabricatorDataNotAttachedException) Attempting to access attached data on DrydockBlueprint (via getImplementation()), but the data is not actually attached. Before accessing attachable data on an object, you must load and attach it.
2
3Data is normally attached by calling the corresponding needX() method on the Query class when the object is loaded. You can also call the corresponding attachX() method explicitly. at [<phabricator>/src/infrastructure/storage/lisk/PhabricatorLiskDAO.php:166]
4PHP message: arcanist(head=master, ref.master=9c056c5cc887), phabricator(head=master, ref.master=8ded0927aa7f), phutil(head=master, ref.master=c72eb747e706)
5PHP message: #0 <#2> PhabricatorLiskDAO::assertAttached(string) called at [<phabricator>/src/applications/drydock/storage/DrydockBlueprint.php:59]
6PHP message: #1 <#2> DrydockBlueprint::getImplementation() called at [<phabricator>/src/applications/drydock/customfield/DrydockBlueprintCoreCustomField.php:12]
7PHP message: #2 <#2> DrydockBlueprintCoreCustomField::createFields(DrydockBlueprint) called at [<phabricator>/src/infrastructure/customfield/field/PhabricatorCustomField.php:129]
8PHP message: #3 <#2> PhabricatorCustomField::buildFieldList(string, array, DrydockBlueprint) called at [<phabricator>/src/infrastructure/customfield/field/PhabricatorCustomField.php:72]
9PHP message: #4 <#2> PhabricatorCustomField::getObjectFields(DrydockBlueprint, string) called at [<phabricator>/src/applications/drydock/controller/DrydockBlueprintEditController.php:43]
10PHP message: #5 <#2> DrydockBlueprintEditController::handleRequest(AphrontRequest) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:237]
11PHP message: #6 phlog(PhabricatorDataNotAttachedException) called at [<phabricator>/src/aphront/handler/PhabricatorDefaultRequestExceptionHandler.php:32]
12PHP message: #7 PhabricatorDefaultRequestExceptionHandler::handleRequestExcep

However, it seems the fix was rather simple since this fixed it for me:

diff --git a/src/applications/drydock/controller/DrydockBlueprintEditController.php b/src/applications/drydock/controller/DrydockBlueprintEditController.php
index 1c75bf7..e94ca6a 100644
--- a/src/applications/drydock/controller/DrydockBlueprintEditController.php
+++ b/src/applications/drydock/controller/DrydockBlueprintEditController.php
@@ -34,6 +34,7 @@ final class DrydockBlueprintEditController extends DrydockBlueprintController {
       }
 
       $blueprint = DrydockBlueprint::initializeNewBlueprint($viewer);
+      $blueprint->attachImplementation($impl);
       $blueprint->setClassName($class);
       $cancel_uri = $this->getApplicationURI('blueprint/');
     }

Event Timeline

mikn updated the task description. (Show Details)
mikn added a project: Drydock.
mikn added a subscriber: mikn.

I apologise for filing issues on it, I know it is against the policy. I've been following Drydock/Harbormaster quite closely and we have been using it for builds for quite a while. Most of the integration you get into Phabricator has been invaluable for us in general. However, the first two outlined issues literally broke all builds for us, and while I understand that you need the agility to be able to break prototype applications, I would hope it is also valuable for you to know how the users who dare to use unsupported applications deal with the changes you make and the problems they encounter, it seems Drydock/Harbormaster in particular is moving towards a more stable place now and the implementations you've landed in with the latest changes look really solid.

If you want us to silently maintain all of our bug fixes towards Drydock/Harbormaster without even mentioning that we encounter these, we can of course do that. I know that Drydock/Harbormaster has garnered a massive amount of interest and a lot of "too early" implementations, and we're one of them - but we're also rather light-weight support wise, I hope.

So my question is, how would you like us to communicate the issues we encounter, if at all, specifically concerning Drydock/Harbormaster from now on and in the future?

So my question is, how would you like us to communicate the issues we encounter, if at all, specifically concerning Drydock/Harbormaster from now on and in the future?

Just wait until it unprototypes (T9252). It's expected that a lot of stuff will break between now and then, or never worked in the first place. Drydock was a particularly prototypey prototype.