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

[http] Expose isKibanaReponse helper in public API #182392

Merged

Conversation

miltonhultgren
Copy link
Contributor

For some other changes I'm working on, I need to be able to distinguish if a route handler returned a IKibanaResponse / KibanaResponse object or some other object that needs to be wrapped before being sent back.

Rather than duplicating this little helper I want to expose it as part of the public API of core.http.

@miltonhultgren miltonhultgren requested a review from a team as a code owner May 2, 2024 15:10
@miltonhultgren miltonhultgren added the release_note:skip Skip the PR/issue when compiling release notes label May 2, 2024
@apmmachine
Copy link
Contributor

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

  • /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
  • run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

@@ -24,10 +24,6 @@ import type {
} from '@kbn/core-http-server';
import mime from 'mime';

export function isKibanaResponse(response: Record<string, any>): response is IKibanaResponse {
return typeof response.status === 'number' && typeof response.options === 'object';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not the most thorough check and would be nice to add unit tests for before making public but overall happy with the idea.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jloleysens I added some tests in d1a8d60 and made some small changes to the helper to make it a bit more strict, let me know what you think!

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@kbn/core-http-router-server-internal 50 48 -2
@kbn/core-http-server 191 193 +2
total -0
Unknown metric groups

API count

id before after diff
@kbn/core-http-router-server-internal 50 48 -2
@kbn/core-http-server 481 483 +2
total -0

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

Comment on lines +11 to +16
describe('isKibanaResponse', () => {
it('expects the status to be a number', () => {
expect(
isKibanaResponse({
status: 200,
options: {},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue having this exposed from the public type package is that we can't even test it against our concrete implementation 😅.

However it's probably fine for now, I don't have a better suggestion / place to put it that wouldn't imply create yet another package, so if @jloleysens is fine with the approach, I'm too.

@miltonhultgren miltonhultgren merged commit 8a52c11 into elastic:main May 6, 2024
17 checks passed
@kibanamachine kibanamachine added v8.15.0 backport:skip This commit does not require backporting labels May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting release_note:skip Skip the PR/issue when compiling release notes v8.15.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants