ANSWERED:Scroll Hatchery Glitch

[pinkgothic]

On 4/2/2018 at 10:49 PM, jocosa said:

Egg Drop Soup is showing 2 Sino's of mine when I add my scroll. That grew up in the summer or 2017.

 

DDF is still also listing four Undine hatchies that I gave away this past Saturday. Even when I do a fresh import there. It shows them on my cell, PC and laptop, so not a cache thing.

 

I'm not sure to what degree you're aware of this, so I'm going to mention this just in case: Importing your scroll only adds codes to DDF, it doesn't remove the codes already there. Trades should thus always have the effect you described, even before any API changes TJ made.

 

If, given this information, you still feel something is amiss, please report it in the DDF thread - that's the only reliable way I can find out something's wrong!  I try to get to fixes as soon as possible, even if the cause is temporary.

 

Regarding the fogball situation: Fogballs are registering as non-existent dragons in API responses now, i.e. the API pretends those codes don't even exist. While DDF has kept removing those (because they're non-existent to it), it's broken the "retain my fogballs" feature, of course. Now that I've coded in a fix, I'm OK with it staying this way, and I've notified the fansites where I noticed the problem with the "missing" fogballs seems to be affecting them. There are some fansites I don't use, though, so I might be missing things.

 

Edit:

 

@TJ09  I just noticed you said fansites are "doing non-standard things" and would like to comment on that.

 

I'm genuinely unsure what you've been told about APIs, but they're meant to be read by programs, not by humans, not even occasionally. That humans do read them occasionally is an accident of circumstance, not by design. You cannot sensibly put notices about your API changing into your API, even if you claim you do this in your API documentation. That is non-standard, and it should be no surprise that the fansites are reacting to this in a non-standard way.

 

The most reasonable thing your API's consumers can do is either break the fansite so the coder is immediately aware something is going on - or just outright ignore the notice, making it dead-weight information.

 

The alternative is to make some kind of complicated system, e.g. one that keeps track of recent notices, and sends new notices as emails, which presumes you have your machine set up properly to send mail (unless you frequently check your Spam folder, or can set up a surefire filter so your emails aren't rejected by your inbox), which (to explain for the benefit of everyone else reading) in this day and age is a little trickier than just supporting mail() in PHP.

 

tl;dr: Please, please, please just announce API changes you want to do somewhere where humans will read it, not as a "notice" in your API response, where no one will reasonably come across the information. Remember, an API is a promise of consistent behaviour - consider communicating more when you plan to make changes to the API. (There are more articles that say this.)

 

Thanks for reading.

Edited April 3, 2018 by pinkgothic

[HeatherMarie]

I still know nothing about APIs, but from what pinkgothic said it seems that the fogball issues are because something changed in the API regarding how fogged dragons are labeled? I have no clue why things were changed in that area, but I must say that as a frequent user of multiple hatcheries this is a *very* inconvenient and confusing change. Fogged dragons not showing up when you add your scroll is sort of understandable, Silvi's is the only hatchery I use who actually did show them... But fogged dragons not being able to be *removed* from hatcheries because of how the API labels them is simply Not Good. Not only does it clutter the hatcheries to a ridiculous degree (over half of the 'ERs' in Allure are fogballs right now) but it's a very confusing and somewhat worrisome scenario when I, as a user, cannot take my own dragons out of a hatchery simply because they are fogged. That's frustrating, because the second I unfog a dragon it's going to start getting views again because it's still in hatcheries, whether or not I'm ready for it to get views. It makes no sense to me. (And please, please don't tell me to unfog every single dragon, take it out of every hatchery, and then re-fog every single dragon, that is no an acceptable workaround.)

[TJ09]

10 hours ago, pinkgothic said:

I'm genuinely unsure what you've been told about APIs, but they're meant to be read by programs, not by humans, not even occasionally. That humans do read them occasionally is an accident of circumstance, not by design. You cannot sensibly put notices about your API changing into your API, even if you claim you do this in your API documentation. That is non-standard, and it should be no surprise that the fansites are reacting to this in a non-standard way.

If the API is specifically-documented as having an code that means "this is a notice," then I do 100% consider treating that as a hard error to be "non-standard."

 

10 hours ago, pinkgothic said:

The most reasonable thing your API's consumers can do is either break the fansite so the coder is immediately aware something is going on - or just outright ignore the notice, making it dead-weight information.

There are ways to handle "warnings" without fully breaking and while still doing something to notify the coder. This is, in fact, exactly what PHP does: any notice- or warning-level errors are logged without failing the rest of the page. Only for severe "there is no sensible way for this request to continue" errors does it completely bail.

 

The API does exactly the same thing, and has for a while for cases where it is known that something will break in the future. If you make requests over HTTP instead of HTTPS, that's not desirable, but it doesn't completely break the ability to return the requested information, so the API continues to do so, while also pointing out that you should ideally stop doing the deprecated thing.

 

10 hours ago, pinkgothic said:

The alternative is to make some kind of complicated system, e.g. one that keeps track of recent notices, and sends new notices as emails, which presumes you have your machine set up properly to send mail (unless you frequently check your Spam folder, or can set up a surefire filter so your emails aren't rejected by your inbox), which (to explain for the benefit of everyone else reading) in this day and age is a little trickier than just supporting mail() in PHP.

Or just have an error log and occasionally look at it. It's built into PHP, even. Having some way of tracking errors, no matter how rudimentary, is going to be useful even when not calling external APIs.

 

10 hours ago, pinkgothic said:

tl;dr: Please, please, please just announce API changes you want to do somewhere where humans will read it, not as a "notice" in your API response, where no one will reasonably come across the information. Remember, an API is a promise of consistent behaviour - consider communicating more when you plan to make changes to the API. (There are more articles that say this.)

No intentionally-breaking changes were made or will be made without notifying people first. As mentioned above, the API will eventually move to be HTTPS-only (as the rest of the site pretty much has), but not without directly telling people first and giving a reasonable amount of time for people to prepare.

 

This isn't Hitchhiker's Guide; I'm not putting important information in the most obscure place possible and expecting people to have known to look for it. If you completely ignore API error code 0 ("Notice") all of the time, literally nothing bad will happen as a result.