Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(client): lodestone availability testing #44

Open
1 of 2 tasks
ReidWeb opened this issue Apr 11, 2022 · 2 comments
Open
1 of 2 tasks

(client): lodestone availability testing #44

ReidWeb opened this issue Apr 11, 2022 · 2 comments
Labels
feature-request New feature or request needs-triage

Comments

@ReidWeb
Copy link
Member

ReidWeb commented Apr 11, 2022

Description

The client should have a mechanism to detect lodestone availability so that requests can be paused by consumers in the event of the site becoming unavailable

Use Case

As a consumer of the lodestone module I should be able to get a clear response indicating the lodestone is down, both as a consumable method .getStatus() and as a uniform response across all entities.

Proposed Solution

Incorporate into all entity fetch operations means to indicate the lodestone is down.

Develop a method routing to a page that should be available consistently and use the response from that to indicate status.

Other information

Curl responses

GET /worldstatus/

image

Acknowledge

  • I may be able to implement this feature request
  • This feature might incur a breaking change
@ReidWeb ReidWeb added feature-request New feature or request needs-triage labels Apr 11, 2022
@ReidWeb
Copy link
Member Author

ReidWeb commented Apr 11, 2022

Testing of code in place to date verified as functional for Character entity, 2022-04-11 12:40:00Z.

Timeout had to be increased in client initialization, timeout errors were being presented

unsure if this is due to my current network connection or due to the server side.

Most likely the former, but verification needed.

@ReidWeb
Copy link
Member Author

ReidWeb commented Apr 11, 2022

It appears HEAD requests respond with a 503 too. So LodestoneClient can have a getStatus() method that uses a HEAD request.

Verified via CI build test run that timeout increase was only needed on my local machine.

image

@ReidWeb ReidWeb moved this to Todo in XIVStats Rebuild Apr 14, 2022
@ReidWeb ReidWeb moved this from Todo to Backlog in XIVStats Rebuild Apr 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request New feature or request needs-triage
Projects
Status: Backlog
Development

No branches or pull requests

1 participant