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

Handle feature not licensed errors #8

Closed
devraj opened this issue Jun 10, 2023 · 2 comments
Closed

Handle feature not licensed errors #8

devraj opened this issue Jun 10, 2023 · 2 comments
Assignees
Labels
documentation Improvements or additions to documentation pending-release Pending release for the nexdt version

Comments

@devraj
Copy link
Member

devraj commented Jun 10, 2023

Gallagher API licenses features by the piece, if a feature isn't available the server responds with a 403 with the following json:

HTTP/1.1 403 Forbidden
Cache-Control: no-cache
Content-Length: 34
Content-Type: application/json; charset=utf-8
Date: Sat, 10 Jun 2023 05:08:12 GMT

{
    "message": "Feature not licensed"
}

the API client should have the ability to handle these responses and throw an exception

@devraj devraj self-assigned this Aug 11, 2023
devraj added a commit that referenced this issue Nov 21, 2023
APIEndpoint is a more fitting name going fowards as we implement
discover and caching REFS #5 and #8
devraj added a commit that referenced this issue Nov 21, 2023
gallagher command centre can have features not available per instance of
the command centre, this makes all the features optional hence if
one is not licensed then an exception is thrown by the client

REFS #8
@devraj
Copy link
Member Author

devraj commented Nov 21, 2023

While experimenting with responses to implement #5 I found that the discovery endpoint does not return an endpoint for features not licensed by the instance.

We should depend on the responses being set to None for the particular endpoints and an exception being thrown by the client.

devraj added a commit that referenced this issue Nov 21, 2023
we are moving towards discovering the api endpoints dynamically, this
is a major refactor in the way the api endpoints are going to work

REFS #5 and #8
devraj added a commit that referenced this issue Dec 6, 2023
the discover endpoints drop the .href portion of the configuration this is
infered by the common runtime code, making it uncessary for each endpoint
to explicitly reference the href propeorty

this also leads us to handing #8 properly as the core runtime can check for
None type of the href property

an OptionalHref type replaces the use of the Mixin for the discover endpoints
additionally these are initialised to None and are overridden if the
feature is avaialble on the command centre

also see commentary in APIEndpoint._discover as to why we are sticking to
initialising the configuration as the result of a function not an assignment
to a class level variable

REFS #5
@devraj devraj added this to the alpha-3 milestone Apr 14, 2024
@devraj
Copy link
Member Author

devraj commented May 1, 2024

Partially handled by #7

We still need to ensure that we handle this in user interfaces to provide meaningful information to the users.

At an API level the developer is expected to catch and handle this.

Leaving this open until documentation is completed.

@devraj devraj added documentation Improvements or additions to documentation pending-release Pending release for the nexdt version labels May 1, 2024
@devraj devraj closed this as completed Jun 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation pending-release Pending release for the nexdt version
Projects
None yet
Development

No branches or pull requests

1 participant