API errors & bugs

#2 - May 22, 2013, 11:15 a.m.

smiley.1438

several item names contain double spaces like: https://api.guildwars2.com/v1/item_details.json?item_id=1794⟨=fr

I don’t see any double spaces in this example. If any exist, it’s likely an issue in the original item data too.

smiley.1438

Some other items have HTML-like markup in their descriptions like https://api.guildwars2.com/v1/item_details.json?item_id=29175
Any strip_tags function should remove it, but it doesn’t look good or may break code if it’s not removed.

That’s intentional, though it should probably be better documented in the future since it’s a completely custom markup. If your goal is to re-create an item’s information box to look like it does in the game, you’ll need those tags to show the right color or style for the text.

#7 - May 23, 2013, 3:32 p.m.

Sorry – server deployment went bad. Should be fixed now.

#15 - May 28, 2013, 2:05 p.m.

smiley.1438:

While updating my local items database i’ve found 5 IDs (43245-43249) which were added today and return a “reply not message” error. What does that mean?

https://api.guildwars2.com/v1/item_details.json?item_id=43249

It means that a backend server wasn’t properly deployed as part of the update this morning. The issue has been resolved and the example item link now works for me.

Thanks for the report!

#25 - June 21, 2013, 7:52 a.m.

Dr Ishmael.9685:

The repeated sectors are for personal story maps. Nemeton Grove, specifically, is also within “A Different Dream” and “Shadow of the Tree”, besides where it normally appears within Brisban Wildlands.

Right. The technical relationship between continents, floors, regions, maps, and sectors is a little bit complex. Each child object could technically be referenced by multiple parent objects. This gives map designers a lot of flexibility, especially when designing unusual maps.

We enforce some practical rules in our map content. For example, floors are only allowed to exist on one continent.

#27 - June 21, 2013, 5:46 p.m.

smiley.1438:

Did we already kill the maps API? O.o

{
	error: 42,
	product: 0,
	module: 9001,
	line: 4119,
	text: "Srv2Route, transaction timeout {#17108}, {P+/Content/GetMapFloor+STS/1.0}"
}

No, sorry, there was a configuration error on our server. It should be fixed now.

#65 - Oct. 9, 2013, 1:10 p.m.

Hi Felicja,

The events.json and event_names.json are flushed on each new release, and get populated as events happen in real time. While the event_details.json enumerates all events ever seen. Some of your cited events such as the “Defeat the Aetherblade Captain” may no longer be happening in newer releases, which is why then don’t get populated in the events.json.

#72 - Nov. 25, 2013, 2:24 p.m.

Things should be coming back to normal. Thanks for the notice.

#80 - Jan. 10, 2014, 8:28 p.m.

I finally fixed the problem with the missing items, recipes, events from the previous reset we had about a month ago. I was hoping they would get re-discovered, but as people noticed this wasn’t happening in a timely fashion. It wasn’t a trivial thing to re-seed this, but it is done now. Let me know if you are still noticing anything missing. Thank you.

#82 - Jan. 14, 2014, 1:05 p.m.

Hi Smiley,

Thanks for the report. We are looking the problem with the ((parenthesis-named)) items.

#84 - Jan. 15, 2014, 8:02 p.m.

Hi Smiley,

It turns out those items were “in-development” items that either were rejected or supposed to be replaced with other items. We are not sure exactly how they got “discovered”. In the meantime I’ve removed them from the API. If they show up again, we’ll have to track down how they are getting discovered.

As for the additional files.json entries: I’ll try to get what I can included as soon as possible and will reply when updated.

#97 - Feb. 18, 2014, 6:57 p.m.

smiley.1438:

The french one seems indeed a bit weird – at least inconsistent to the others. So in french would be possibly “Cercle de feu” -> “Territoires frontaliers (Cercle de feu)”. Since these names apparently are taken directly from the game (including bugs) i guess theres some string replacement done here. Further explaination by a dev would be appreciated

I investigate this a bit. It turns out as you suspected there is some concatenation at play here, as dictated by some special markup and is different for each language translation. As in:

• EN: %str2% Borderlands
• FR: Territoires frontaliers (%str2% )
• ES: Tierras fronterizas de[pl:""] %str2%
• DE: %str1% Grenzlande

Unfortunately, what we render in the API is after the concatenation markup is trimmed out (and presumably replaced with an empty string). I did a brief investigation on how I might be able to render the name with markup, but it will require more work than I can afford right now. I’ll keep this noted as a bug.

thank you!

#160 - Sept. 15, 2014, 1:48 p.m.

StevenL.3761:

/v2/commerce/listings returns literal “null” strings when a bulk request specifies non-existent or account-bound item identifiers.

https://api.guildwars2.com/v2/commerce/listings?ids=-2,-3,6,24

You might have to refresh the page a couple of times to see it.

I tried two different serialization engines, and both fail to correctly recognize these values as null.

We’re taking a look at this and have a plan for how to fix. That’s a fun one, good catch!

#164 - Sept. 29, 2014, 1:11 p.m.

StevenL.3761:

Pat Cavit.9234:

StevenL.3761:

/v2/commerce/listings returns literal “null” strings when a bulk request specifies non-existent or account-bound item identifiers.

https://api.guildwars2.com/v2/commerce/listings?ids=-2,-3,6,24

You might have to refresh the page a couple of times to see it.

I tried two different serialization engines, and both fail to correctly recognize these values as null.

We’re taking a look at this and have a plan for how to fix. That’s a fun one, good catch!

It’s better now, but there are still some inconsistencies that make my code crash.

Right now, the listings service returns garbage values instead of an error for some identifiers:

OK: https://api.guildwars2.com/v2/commerce/listings/0
Not OK: https://api.guildwars2.com/v2/commerce/listings/1

Same story for the prices service.

OK: https://api.guildwars2.com/v2/commerce/prices/0
Not OK: https://api.guildwars2.com/v2/commerce/prices/1

We can look at standardizing those some, but both are correctly returning a 400 bad request. It gets exciting since the API is a layer on top of many backend services and those don’t all agree on how to respond to things.

That said, you should always determine if the request was an error by inspecting the HTTP status code & not the contents of the response.

#166 - Sept. 29, 2014, 1:20 p.m.

StevenL.3761:

I can’t check on my phone, but I don’t believe that ID 1 returns an error code. Just HTTP 200 and a garbage value.

Clearly still too early, my brain flipped your “OK” and “Not OK” values. Sorry!

#169 - Oct. 1, 2014, 6:40 p.m.

StevenL.3761:

I’m not sure if this is even worth looking at, but there’s still that bug where IIS crashes with a text/html response when the parameter list gets too big. Probably because IIS/ARR and the private API do not agree on the maximum URL length.

Example: http://pastebin.com/nXSR8kSb

Garbage in, garbage out!

Not a lot we can easily do about that right now.

#171 - Oct. 2, 2014, 12:27 p.m.

StevenL.3761:

I think this behavior is caused by a setting in the Request Filtering module (http://www.iis.net/configreference/system.webserver/security/requestfiltering). The article perfectly matches the behavior that I’m seeing.

When request filtering blocks an HTTP request, IIS 7 will return an HTTP 404 error to the client and log the HTTP status with a unique substatus that identifies the reason that the request was denied.

So, to disable the filter:

• Open IIS Manager and connect to the gateway server that routes the requests
• Click the root node of the server in the “Connections” panel
• Double click “Request filtering” in the “Features View” panel
• Click “Edit Feature Settings…” in the “Actions” panel
• Change the maximum URL and query string length to 4294967295 (max), or something more sensible than 2048/4096

The defaults are sensible and we aren’t going to change them for now. Don’t request 500 IDs at once, especially since the max we’ll return to you is 200.