Creating new API fails with "API not found"

[kaloyan-raev]

If I try to create new API I get an error message: API "MyAPI" not found.

The API is actually created but the page is not refreshed and the error message is shown. I need to either create another API or refresh the browser to see the new API in the list.

I remember this worked correctly in 1.0.0. It seems to be a regression in 1.0.1.

[weierophinney]

I have not been able to reproduce this at all with current master. Can you pull current master for the admin, and indicate if it's still an issue? If so, also let me know what OS and browser you are using (as well as browser version).

[kaloyan-raev]

I still have the issue with admin from dev-master.

I run Ubuntu 13.04 with Chrome 35.0.1916.114 beta. Same with Firefox 26.0.

[kaloyan-raev]

@weierophinney could you give me any hint how I can debug the issue?

[jguittard]

I can reproduce the same issue from Zend Studio Apigility editor and Chrome 36.0.1985.125 (Mac OS 10.9.4)

[weierophinney]

@kaloyan-raev and @jguittard -- I've not been able to reproduce this reliably, so I'm only guessing at a solution -- which you can see in #213. If you could try this, I'd appreciate it.

To do so, add the following section to your composer.json:

"repositories": [
    { "type": "vcs", "url": "https://github.com/weierophinney/zf-apigility-admin.git" }
]

Then change the zf-apigility-admin dependency under require-dev to read:

"zfcampus/zf-apigility-admin": "dev-hotfix/promise-chains as 1.0.3",

and run composer update.

I did find one new problem: ModuleEntity did not have a defined entity_identifier_name, which was causing new APIs to return an error after creation, even when successful (due to inability to render). I had not seen that until today, though, which makes me think that's related to changes in zf-hal/zf-rest in the past week. (I've fixed it in that same PR.)

Let me know if this resolves it or not.

[weierophinney]

Alternately, use the current master branch, as I've merged #213 already.

[jguittard]

Used master & #213, did not change the issue... :(

[weierophinney]

Ugh.. then I'm out of ideas, currently, as I still cannot reproduce the issue. :-/ If either of you can, and can help me debug why it's happening, I'd greatly appreciate it.

[lumberjacked]

I am also having this same problem and honestly have not been able to get apigility to work completely yet. I just started yesterday trying to install apigility following the Rest tutorial. After setting everything up and going into Api and creating "Status" after hitting "Create New API" the message at the bottom displays API "Status" not found. No errors show up in the console when running php development server. After refreshing the page the new Status api does show up in the list. Though after going in and updating the parameters to use Zend\Stdlib\Hydrator\ObjectProperty and changing the Service Class Names and saving. It shows a message that it updated successfully, but going back to the Api button it shows Status in the list but will not allow you to select it. Hitting refresh again the Status api does not show up in the list anymore. Restarting the server doesn't help any as well.

Current setup Ubuntu 14.04 php development server and apache Server version: Apache/2.4.7 (Ubuntu) php - PHP 5.5.9-1ubuntu4.3 chrome - Version 36.0.1985.125

[lumberjacked]

After starting over and getting to updating Zend\Stdlib\Hydrator\ObjectProperty and Service Class names and hitting save. Displays Successfully updated. If you hit the settings button at the top it will produce an error in the console.

#0 /home/lumberjacked/workspace/apigility/vendor/zfcampus/zf-hal/src/Metadata/MetadataMap.php(81): ZF\Hal\Metadata\Metadata->__construct('Status\Entity', Array, Object(Zend\Stdlib\Hydrator\HydratorPluginManager))
#1 /home/lumberjacked/workspace/apigility/vendor/zfcampus/zf-hal/src/Metadata/MetadataMap.php(40): ZF\Hal\Metadata\MetadataMap->setMap(Array)
#2 /home/lumberjacked/workspace/apigility/vendor/zfcampus/zf-hal/Module.php(69): ZF\Hal\Metadata\MetadataMap->__construct(Array, Object(Zend\Stdlib\Hydrator\HydratorPluginManager))
#3 [internal function]: ZF\Hal\Module->ZF\Hal\{closure}(Object(Zend\ServiceManager\ServiceManager), 'zfhalmetadatama...', 'ZF\Hal\Metadata...')
#4 /home/lumberjacked/workspace/apigility/vendor/zendframework/zendframework/l in /home/lumberjacked/workspace/apigility/vendor/zendframework/zendframework/library/Zend/ServiceManager/ServiceManager.php on line 909

[weierophinney]

@lumberjacked Please bring your latest issue to the mailing list -- the stack trace you're getting indicates that you're specifying a class in your metadata map that does not exist. As such, it's unrelated to the original issue reported here.

[weierophinney]

As I've closed a few other issues that duplicate this, I want to ask the following:

IF YOU CAN REPRODUCE THE ISSUE, please, please, please try and debug. Determine what calls are being made, what payloads are sent, what is received (full payload: status, headers, and content), and also the order in which calls are made. I suspect that due to the async nature of the calls, it's possible that the call to fetch may be happening before the call to create the API has finished.

On top of that, I'm very curious to see if browsers may be overly aggressive in caching the GET call for retrieving the list of APIs. If you are seeing 304s, I want to hear about that; that's something we may be able to fix easily with the zf-http-cache module from Corentin.

My point is this: I have never been able to reliably reproduce the issue, which means any attempts I make to fix the situation are literally shots in the dark. I need your help!

[webaaz]

Same problem with chrome and firefox on ubuntu 14.04. @weierophinney : There's no 304.

I'm debugging!

[jguittard]

Martin, do you use master ? Should be fixed by now.

Le 19 août 2014 à 18:03, Martin Supiot notifications@github.com a écrit :

Same problem with chrome and firefox on ubuntu 14.04. @weierophinney : There's no 304.

I'm debugging!

— Reply to this email directly or view it on GitHub.

[kaloyan-raev]

One of our QAs can reproduce it with Apigility 1.0.4 on a test Mac system.

[weierophinney]

@kaloyan-raev Let me know if you want me to assist in debugging (I can do via SSH if necessary).

@webaaz Are you using an SSD by any chance? Our suspicion at this time is that file operations are completing, but that the filesystem is not completing the write for a duration of time after the process ends; SSDs tuned for performance can display this behavior -- which is why we see only a small portion of people having the issue, and why I've been unable to recreate it personally.

[webaaz]

Yes I'm on ssd! I'll try on hdd!

[webaaz]

@jguittard Yes I'm on master. I got some files created, but the interface don't care or don't know ... A refresh don't list the APIs

[webaaz]

It's ok. I got two entry point on my project.

• index.php using config/application.config.php
• api.php using config/api.php

The API creation process update application.config.api, but not config.api.php, so the files are here, but the module is not loaded.

Not really a bug finally. Perhaps we can improve the error message

[webaaz]

So, not a SSD bug for me ;-)

[FnTm]

Can reproduce on a VM, running Linux Mint 16. Tried removing/reinstalling Apigility - same results. Will setup xdebug and try stepping through the process to see where this goes wrong. Actually, if needed, I can also share the VM, in the hopes, that the same could be reproduced on another machine.

What happens is, that the API gets created, but is not shown in the list in http://localhost:8888/apigility/ui#/api, but can be edited.

[FnTm]

A bit of further investigation has revealed that, at least for me, this is a problem with the timing of the subsequent request to navigate to the new api. If I put a breakpoint in index.php, thus manually allowing requests through, they all proceed succesfuly.

[Amadon]

Hello, i had the same issue when i use php version 5.4.36-0+deb7u3. After update php I can normal create DB-Adapter and APIs

and i try to use HipHop VM 3.5.0. It works too.

[AprilMedinger]

I created a new API yesterday worked with it all day..left to go home for the evening.. this morning.. saw the following notification:

SECURITY UPDATES (2.3.6) ZF2015-03 Zend\Validator\Csrf..recommend upgrading immediately.

I updated.. and then 'API NOT FOUND' Ran update dependencies..

• Removing zendframework/zendframework (2.3.6)
• Installing zendframework/zendframework (2.3.7)

Now works like a charm! APIs all good to go.. Just sharing :)

[rrubio]

I've just done an update and getting the same annoying mesage API "gcmag" not found, i am using ZendStudio 12 Apigility Editor (not sure if it makes any difference). I tried updating the framework to "2.3.7" and still getting the same error. Was there ever a final fix for this? my composer file is a per below. Did i mention i'm a newbie with "apigility" :-)

Any help is much appreciated.

{ "name" : "zfcampus/zf-apigility-skeleton", "description" : "Skeleton Application for Apigility", "require" : { "php" : ">=5.3.23", "zendframework/zendframework" : ">=2.3.7,<3.0.0", "zfcampus/zf-apigility" : "~1.0", "zfcampus/zf-apigility-documentation" : "~1.0", "zfcampus/zf-development-mode" : "~2.0", "zfcampus/zf-rest": "~1.0-dev", "zfr/zfr-cors" : "1.*", "sunra/php-simple-html-dom-parser": "v1.5.0" }, "require-dev" : { "zendframework/zftool" : "dev-master", "zendframework/zend-developer-tools" : "dev-master", "zfcampus/zf-apigility-admin" : "~1.0", "zfcampus/zf-apigility-welcome" : "~1.0", "zfcampus/zf-deploy" : "~1.0", "zfcampus/zf-rest": "~1.0-dev", "zfr/zfr-cors" : "~1.0", "zend/zend-studio-development-mode" : "~1.0" }, "support" : { "email" : "apigility-users@zend.com", "irc" : "irc://irc.freenode.net/apigility", "source" : "https://github.com/zfcampus/zf-apigility-skeleton", "issues" : "https://github.com/zfcampus/zf-apigility-skeleton/issues" }, "keywords" : [ "api", "apigility", "framework", "zf2" ], "extra" : { "branch-alias" : { "dev-master" : "1.0-dev", "dev-develop" : "1.1-dev" } }, "config" : { "process-timeout" : 5000 }, "license" : "BSD-3-Clause", "type" : "library", "homepage" : "http://apigility.org/" }

[jguittard]

Depending on the hardware you're using, it's indeed the same annoying issue related to hard drives being slow to write the generated files. This will no longer happen with the upcoming version 1.1 of Apigility. Stay tuned :)

Julien.

Le 15 avr. 2015 à 08:40, rrubio notifications@github.com a écrit :

I've just done an update and getting the same annoying mesage API "gcmag" not found. I tried updating the framework to "2.3.7" and still getting the same error. Was there ever a final fix for this? my composer file is a per below. Did i mention i'm a newbie with "apigility" :-)

Any help is much appreciated.

{ "name" : "zfcampus/zf-apigility-skeleton", "description" : "Skeleton Application for Apigility", "require" : { "php" : ">=5.3.23", "zendframework/zendframework" : ">=2.3.7,<3.0.0", "zfcampus/zf-apigility" : "~1.0", "zfcampus/zf-apigility-documentation" : "~1.0", "zfcampus/zf-development-mode" : "~2.0", "zfcampus/zf-rest": "~1.0-dev", "zfr/zfr-cors" : "1.*", "sunra/php-simple-html-dom-parser": "v1.5.0" }, "require-dev" : { "zendframework/zftool" : "dev-master", "zendframework/zend-developer-tools" : "dev-master", "zfcampus/zf-apigility-admin" : "~1.0", "zfcampus/zf-apigility-welcome" : "~1.0", "zfcampus/zf-deploy" : "~1.0", "zfcampus/zf-rest": "~1.0-dev", "zfr/zfr-cors" : "~1.0", "zend/zend-studio-development-mode" : "~1.0" }, "support" : { "email" : "apigility-users@zend.com", "irc" : "irc://irc.freenode.net/apigility", "source" : "https://github.com/zfcampus/zf-apigility-skeleton", "issues" : "https://github.com/zfcampus/zf-apigility-skeleton/issues" }, "keywords" : [ "api", "apigility", "framework", "zf2" ], "extra" : { "branch-alias" : { "dev-master" : "1.0-dev", "dev-develop" : "1.1-dev" } }, "config" : { "process-timeout" : 5000 }, "license" : "BSD-3-Clause", "type" : "library", "homepage" : "http://apigility.org/" }

— Reply to this email directly or view it on GitHub.

[rrubio]

Hi Julien,

Thanks for getting back, really appreciate it and looking forward to the new version ;-)

In the meantime though? is there a work around? you are right.. I am on SSD Mac. So the problem is on my side.