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

[Reporting/np-k8] Remove several oncePerServer usages #50997

Merged
merged 17 commits into from
Nov 22, 2019

Conversation

tsullivan
Copy link
Member

@tsullivan tsullivan commented Nov 19, 2019

Summary

Pulled from #50973

This is part of Reporting New Platform migration efforts: removing references of the Hapi server object.

Working on New Platform changes to remove references to the Hapi server object caused a trickle of TS check failures. This PR handles mostly the fixes for the failures, as well as the low-fruit changes for removing references to the server object.

  • We need to make sure that these changes don't create a negative performance impact.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

For maintainers

@tsullivan tsullivan added (Deprecated) Feature:Reporting Use Reporting:Screenshot, Reporting:CSV, or Reporting:Framework instead v8.0.0 release_note:skip Skip the PR/issue when compiling release notes Team:Stack Services Feature:NP Migration v7.6.0 labels Nov 19, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-stack-services (Team:Stack Services)

@elasticmachine
Copy link
Contributor

💔 Build Failed

'xpack.reporting.exportTypes.csv_from_savedobject.executeJob.failedToAccessPanel',
{ defaultMessage: 'Failed to access panel metadata for job execution' }
);
}
Copy link
Member Author

Choose a reason for hiding this comment

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

This had to be added for types reasoning: panel can be undefined per the TS fixes in this PR.

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@tsullivan tsullivan requested review from timroes, joelgriffith and a team November 20, 2019 18:00
@@ -193,9 +198,10 @@ export interface JobParamPostPayload {

export interface JobDocPayload {
headers?: Record<string, string>;
jobParams: object;
jobParams: any;
Copy link
Member Author

@tsullivan tsullivan Nov 20, 2019

Choose a reason for hiding this comment

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

The JobDocPayload's jobParams depends on what kind of job it is. It could be an object with savedObjectId (CSV export) or a URL (PDF). Getting to a point where there is a "base" JobDocPayload type that is extended for more specific contexts, has been hard with the way I've tried: any minor change can cause seemingly random TS checking to fail, at any place in Reporting code.

For now, I'm switching this to any but I think the correct way to do this is with TypeScript Generics. At some point in the future, I could see that the way to get the JobDocPayload type in a specific context would be to use a generic:

let fooPayloadA: JobDocPayload<JobParamsSavedObject>;
let fooPayloadB: JobDocPayload<JobParamsUrl>;

) => Promise<object>;
) => Promise<JobParamsSavedObject | JobParamsUrl>;

export type ImmediateCreateJobFn = (
Copy link
Member Author

Choose a reason for hiding this comment

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


function createJobFn(server: ServerFacade) {
export function createJobFactory(server: ServerFacade): ESQueueCreateJobFnDiscoverCsv {
Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's go with this one and I'll close the other

Copy link
Member Author

@tsullivan tsullivan Nov 20, 2019

Choose a reason for hiding this comment

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

Inspired by @joelgriffith's PR, I think it would be better to do this like:

export const createJobFactory: CreateJobFactory = function createJobFn(server: ServerFacade) {

That's what I was originally looking for in my changes, but couldn't get the JS right.

import { JobParamsPNG, ESQueueCreateJobFnPNG } from '../../types';

function createJobFn(server: ServerFacade) {
export function createJobFn(server: ServerFacade): ESQueueCreateJobFnPNG {
Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

Oops, bug: should be createJobFactory

@@ -39,7 +38,7 @@ const getReportingHeaders = (output: JobDocOutputExecuted, exportType: ExportTyp
return metaDataHeaders;
};

function getDocumentPayloadFn(server: ServerFacade) {
export function getDocumentPayloadFactory(server: ServerFacade) {
Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Contributor

@joelgriffith joelgriffith left a comment

Choose a reason for hiding this comment

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

Code LGTM, I didn't see any test changes though? Guess that this is more side-effect in nature anyways.

@tsullivan
Copy link
Member Author

test changes

There potentially would have been changes need in some of the mock objects that are tests are using for job params, and job payload, but since those are typed as any in this PR, no changes are needed in there.

@tsullivan
Copy link
Member Author

@timroes can I please trouble you to take a 2nd look at this PR, or delegate someone outside of Stack Services to do so?

I'd like to start getting outside teams a little familiar with Reporting code, as well as gather feedback on our types and integration with the new platform. The Reporting code going through change for New Platform migration are what take in all the integrations that all apps have with Reporting (job generation, deriving export type from the job params, etc).

@tsullivan
Copy link
Member Author

@elasticmachine merge upstream

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@tsullivan
Copy link
Member Author

Hi Joel, since this almost was merged with a bug in it. The import reference bug would have been caught if the kibana/x-pack/legacy/plugins/reporting/export_types/*/server/index.js files were converted to TypeScript, but I'm going to hold off on that for a later PR. We talked about some ways we want to change up how export types get registered, and these are the files where that happens.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@tsullivan tsullivan merged commit 1034bb4 into elastic:master Nov 22, 2019
@tsullivan tsullivan deleted the reporting/remove-onceperserver-i branch November 22, 2019 03:06
tsullivan added a commit to tsullivan/kibana that referenced this pull request Nov 22, 2019
* [Reporting/np-k8] Remove several oncePerServer usages

* ts fixes 1

* ts fixes 2

* more ts fixes

* more ts fixes

* more ts fixes

* ts simplification

* improve ts

* remove any type for jobParams and define JobParamsSavedObject and JobParamsUrl

* ts simplification

* Fix ts

* ts simplification

* fix ts

* bug fix

* align with joels pr
@elasticmachine
Copy link
Contributor

💔 Build Failed

tsullivan added a commit that referenced this pull request Nov 25, 2019
* [Reporting/np-k8] Remove several oncePerServer usages

* ts fixes 1

* ts fixes 2

* more ts fixes

* more ts fixes

* more ts fixes

* ts simplification

* improve ts

* remove any type for jobParams and define JobParamsSavedObject and JobParamsUrl

* ts simplification

* Fix ts

* ts simplification

* fix ts

* bug fix

* align with joels pr
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
(Deprecated) Feature:Reporting Use Reporting:Screenshot, Reporting:CSV, or Reporting:Framework instead Feature:NP Migration release_note:skip Skip the PR/issue when compiling release notes v7.6.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants