A bug was found related to retrieving card list data for non-default card lists from the main set page, specifically observed with the Rarity Collection 20th Anniversary Edition. Despite receiving valid HTML responses from the site's asynchronous requests, these card lists were appearing empty. This was an isolated event - as of this update the site admins have been unable to find an issue and the site loads the non-default lists just fine for them
To resolve this, when encountering such issues, the wrapper will now reference the missing card list pages directly from the set navigation box located above the general card lists on the main set page. These alternate lists have been verified to be complete and accurate for the required information.
There was a bug after the v0.4.0 update that caused cards queried through set.cards to not populate their data properly.
type Set {
...
printType: String
printNotes: String
...
}is now
type Set {
print: PrintDetails
}
type PrintDetails {
type: String
notes: String
}The returned structure of the main query function has been overhauled. Let's take a look at an example to see how this changes things.
query EX_QUERY($name: String!) {
card(name: $name) {
error {
code
message
}
name {
english
korean {
html
}
}
}
}// ... setup
const query = " ... " // the above query
const variables = { name: "Dark Magician" }
const result = await api.query(query, variables)
console.dir(result, { depth: null })This would give you the following result:
{
data: {
EX_QUERY: {
card: {
error: {
code: 200,
message: 'OK'
}
name: {
english: 'Dark Magician',
korean: {
html: '블랙 매지션'
}
}
}
}
}
}With the new changes, the error object has been unbound from the schema's root query api in favor of two nullable arrays - "errors" and "warnings". This retains the flexible nature of not throwing an error for bad data, and adds to it the even-more-flexible nature of not throwing random errors for every minute issue that may or may not arise. It even gives more readable and obvious logging messages. Let's take a look at a new query and response.
query EX_QUERY($name: String!) {
card(name: $name) {
name {
english
korean {
html
}
}
}
}{
data: {
EX_QUERY: {
card: {
name: {
english: 'Dark Magician',
korean: {
html: '블랙 매지션'
}
}
}
}
},
errors: [],
warnings: []
}Errors and warnings will assume the following shape:
{
culprit: string, // this is the name of the query that produced the error/warning
code: number, // a very descriptive code number denoting what type of error/warning it is
log: {
message: string, // the main message of the error/warning
payload: unknown, // any data that is pertinent to understanding the error/warning
}
}Here's an example of the errors and warnings in action:
query {
card(name: "Dark Mgician") {
# ^^^^^^^ Notice the typo here
name {
english
korean {
html
}
}
}
}{
data: { query: { card: {} } },
errors: [
{
culprit: 'card',
code: 404,
log: { message: 'No data could be found for the page "Dark Mgician"' }
}
],
warnings: [
{
culprit: 'card',
code: 300,
log: {
message: '[getOneCardByNameResolver] Data missing. There is likely an error log explaining this.'
}
}
]
}As you can see, it's quite easy to lead yourself to the solution given this new structure and information.
With the return structure overhaul there comes also an error and warning overhaul inherent to it. Codes have been standardized, defined, and strictly enforced, and messages are deliberate and informative. The codes and their meanings are as follows:
3xx- These are reserved for warnings4xx- These are reserved for errors originating from data collection, such as scraping and/or api errors5xx- These are reserved for internal errors, such as GQL query syntax errors or fatal errors (usually my fault; sorry in advance!)
300 <Missing Data>- Describes data that is missing when it was expected by a parser or formatter.301 <Missing/Corrupted Data>- Describes data that is missing or corrupted as a resource on the fetched endpoint. (to be clear, it's data that should exist, but for some reason doesn't)
400 <Bad Request>- The data that was requested doesn't match the data that was found. For instance, if a name you provided for thecardquery matches a set instead, etc.402 <Scrape Failed>- A scraping request failed. Most likely this will be caused by Yugipedia not being in good health for one reason or another.403 <API Error>- The underlying SMW/MW API produced an error.404 <Data Not Found>- The data you requested doesn't exist as a resource on the providing server. This will most likely occur due to spelling errors.
500 <GQL Error>- These errors are produced by the underlying GraphQL interpreter, usually denoting syntax errors or issues.501 <Unknown Error>- The errors that was raised is known to be unknown. These will be random, uncaught and untested errors that are thrown by anyone from anywhere down the chain. These shouldn't be common, but still might occur.