MapFlightEx returns 200/OK but empty

FlightAware AeroAPI
21

Hi @cbw,

Firstly, let me try to laugh, to not cry, on how sad (I’m using the word “sad”, to not use possible offensive words) you’re dealing the case.

It does not make sense to respond privately all my questions I’ve posted here, since they are not secret, and they are already published in this topic. All questions and answers could be useful for any other client using your FlightXML APIs.

I’m sad that you did not apologise for avoiding to answer my questions, basically you just ignored and ignored, and just when I published my last post you did something! My last waiting time from a feedback of yours was from 6th March!!! What you have responded now privately did not have any word on this!!! Very Very sad! What It makes me more sad is that you do not admit your faults, even you being a manager, with much more responsibilities.

I’m also sad that you did not delegate this issue to other staff, if you could not handle it properly.

Please, as an advice, I say to you, be more humble and honest. Admit your faults and limitations, please, you would be a better person and manager, and your clients and your colleagues will appreciate that.

It is sad that you still (from your private response) don’t admit and understand that this problem could affect any of your clients, not only with me, so you should understand that this is a global problem, but some of your clients are not worried (or don’t even know /are not awared of) about these cases and/or not worried of being charged for null responses due server/unknown errors.

You came (again) with a offer of 15% discount on FlightXML2 API to try to “resolve discrepancy”. Think about it, you offered that to me, so you should offer the same to all of your API clients also. Again, you would be unfair, in this case with them.
You did not said this to me: “Hi, take here a cookie and keep calm”, but it seems really like you said that to me. Sorry, I will not accept your offer. I’d rather prefer pay the fair price (hopefully) for your services, being billed correctly, and paying the correct price. It is a matter of transparency, fairness and principles.

For now, I will continue to use your API service, till I don’t find a better service. I don’t dislike your service, but I don’t agree with your billing policy regarding this topic and also with your responses @cbw, as a manager, I was expecting more from you. And other “minor” things also. I know perfection does not exists, but we could always improve. Taking suggestions to improve our actions, personality, product/service, anything.

If you don’t want to change, if you think its all fine, your policies, the way you deal with your clients, your products/service, I can’t do anything else than just giving my opinion on this, disagreeing and trying to make suggestions for you to improve. We are all here to improve and to learn, sometimes with errors.

Also I’ll give an evaluation you your service till now:

  • APIs methods/data quality/reliability - OK - * reliability should be improved regarding this type of cases, for example.
  • API’s/plans documentation - Average/poor as mentioned above and in other posts (You already admitted you have that to improve)
  • Support - Average/poor * Generally you take too much time to give a feedback, having the client to insist in a feedback from yours
  • API responsivness - Average (could be faster responses, but its ok)
  • Requests History provided in your site - Too much delay time (+/- 2 hours latter to see requests history)

I’m also posting below what was your last private (not private anymore) message regarding this (could be useful for other clients)

13 days later
cbwFlightAware Staff
5h

Hi Msousajit,

Please find my responses below.

Regarding updates and plans of your API (FlightXML3), I guess you are planning to release some methods regarding maps and imagery, some like you have in your FlightXML2 like MapFlightEx that we are using in our tests to integrate, right?

That is correct. There will be methods in FlightXML3 similar to MapFlightEx

So, regarding your FlightXML3 API do you have an idea when to release final stable version with maps and imagery and all the features you describe in all plans?

I do not currently have a firm date on when these methods will be available in FlightXML3 Beta

We plan to use Maps and Imagery methods from FlightXML3 but we don’t have yet any methods to test, and then We’ll use just one api key.

You will not be able to test this until there is a method available to test in FlightXML3 Beta, which means you will need to continue to use FlightXML2 for these methods.

most of all, I don’t agree with your offer, even if firstly I said that I’ve accepted it in a compromise from your side that you would change your policies latter.

If you would not like to agree to the offer that I have presented, you have the ability to decline and either be charged according to the policy or find another service to provide the information you are looking for. I would rather find an agreeable solution and have you continue to use FlightAware for your flight information. I have provided an option that would offset any returns that are erroneous and likely provide you a benefit. Additionally, there has not been an agreement that, with the offer presented to you, we would be changing our billing policies for FlightXML.

The billing methods differ from FlightXML2 and FlightXML3, so I’m wondering how we’ll tackle this, if the “remedy” to apply would be the same.

When there is a release of the method for FlightXML3 Beta and there are still discrepancies in returns, we can work out an agreeable solution.

I am still offering what I sent you if you want to continue to use FlightXML. Please let me know and I will arrange to have the account properly credited. I am also opening a ticket so that the team can look into ways to make the returns more reliable. I will be in touch with you when I hear from the team. This may take some time for me to provide an update, but in the meantime, I am happy to offer the discount as provided previously.

With all of this, I hope you consider my advices @cbw, in a hope you mitigate all the wrong things that happened in this process. I’m still hoping you do something to improve your service, improving at least reliability of your API responses.

Thanks, I hope you don’t take this as an offensive message, but all of this made me really sad.

22

msousajit,

Seeing as this is a discussion about your account, I decided to have the discussion with you. If you want to make these discussions public, that is at your discretion.

Think about it, you offered that to me, so you should offer the same to all of your API clients also. Again, you would be unfair, in this case with them.

You have brought up an issue about a single method that other clients may or may not be using, without providing any insight into how many of these queries you are making are failing. I am taking your word that the queries fail and offering a remedy to your claim.

You have written that even if there is 1 query that fails, you should not have to pay for that query. I do not disagree with your thinking on this, which is why I am trying to mitigate the problem. Unfortunately, I did not write/create the FlightXML product nor the policies, nor am I able to single handedly change the policy as this would require an overhaul of how FlightXML is written. I am not actually a developer and am not able to make these changes myself. As I mentioned previously I have opened a ticket to increase the reliability for the method and will be happy to be back in touch when I hear from the team. Additionally I have attempted to mitigate the concerns you are having to provide a mutually beneficial solution.

Thank you for providing your evaluation of the FlightXML product, I will pass that on to the team that works on the FlightXML product.

If you have any other comments regarding this topic, please post here. If you have any other questions outside the purview of this context, please open another topic and we will be happy to assist.

23

@cbw,

That method is used by many clients, I see it by many posts from clients using that method. And that method is from a stable API FlightXML2, not the “unstable” FlightXML3. So that don’t seem a good excuse.

Regarding on how many queries are failing, I’ve already discussed here:

At least, now you have admitted you are not disagreeing with me regarding the fairness (or lack of fairness) of being billed by queries that fail due server error/unknown errors (client perspective), or missing/incorrected data from your side (data that you should have, especially in this case of an enroute flight) and I’m glad to hear that.

So, if you’re the manager (or one of the managers) you have some authority to do things like: delegating to other colleagues problems you can’t or unable to deal; you could discuss with other managers, or other superior about this. Since you’re not a technical person (developer, IT manager,…), you could bring this issue to the IT manager in charge and try to expose the problem and try to change the policies with them. I’m also glad that you at least, opened a ticket to try to increase the reliability, (that should be not only for that method, but all api methods), and I’m hoping something would change regarding this, waiting for your feedback, hoping also that it doesn’t take too much time.

Still no apologies from your side. Still sad that you did not recognized your faults on dealing this case.
But still hoping you have learned something from this.

24

Hi @cbw,

Regarding the ticket you’ve opened to increase the reliability of your API methods, you still don’t have any response from the team?
More than a month have passed since you created the ticket… you should have any response on that I guess…

Waiting for your feedback.

Thanks.

25

In speaking with the developers we are continuing to work on software that we increase the reliability of some of the methods in the API. I was not provided a firm timeline of when the work is to be completed, but it is still ongoing.

26

Will you communicate back when the work is completed?
I would like to know how you improved the reliability regarding this kind of situations.

Thanks,

27

As mentioned previously, I will be in contact when we have a resolution to your issues.

As I mentioned previously I have opened a ticket to increase the reliability for the method and will be happy to be back in touch when I hear from the team.

1 Like
28

One year has passed since the creation of this issue.

I really want to believe you have made improvements since then, and also improvements regarding solving this kind of issues, but you forgot to give a feedback (nothing that I wasnn’t expected from you giving past interactions and seeing your interactions in the forum).

So, do you have something to tell me about this?

Thanks.

29

Hello

Is anybody there?

30

Since the start of this thread error handling in FlightXML2 has been largely updated to prevent empty responses. Endpoints use more standardized keywords like “NO_DATA” for unanticipated results. MapFlightEX can respond with a {"error": "NO_DATA MapFlightEx failed to generate map"}.

32

Hello @dogrock

This whole case described in this thread was very badly treated from FlightAware staff mainly by your colleague above, in vary ways.
One way was not giving timely responses to your client questions, other is avoiding responsibilities, other not giving proper solutions to problems, among others.

I am deducting that, since I didn’t received updates for a long time on this, that the problem remains, and nothing has happened.

@dogrock I appreciate any effort on improvement of your service,yet, your response does not solve the problem I’ve mentioned in the thread.

Did your updates respond to these questions?

  • Are those queries billed?
  • Are those NO_DATA server error responses?
  • How do I distinguish from a response to a query that will not give any useful response for the client and a response that failed by some reason that tell me that I can obtain correct information in my next request.
    ** Imagine for question above, querying for a image map during an inflight time of 12h in every 5 minutes.

Lastly I want to not being billed for server response errors, and in those cases of 200OK NO_DATA, since those queries will be billed, have some indication to give to my application to not do more queries for a flight that will never return a valid/useful response to our application (E.g. NO_DATA)

Thanks.