[FLINK-38899][runtime-web] Introduce the Rescales/History sub-page for streaming jobs with the adaptive scheduler enabled

[och5351]

What is the purpose of the change

• [FLINK-38899][runtime-web] Introduce the Rescales/History sub-page for streaming jobs with the adaptive scheduler enabled
• The pr is not blocked by FLIP-495 completion and is independent sub-task in FLIP-487.

Brief change log

Adds the 'Rescales/History' tab and 'HistoryDetail' subpage in relation to [FLINK-38897][Runtime/REST] Introduce /jobs/:jobid/rescales/config endpoint to REST API #27580.

Dependent PRs

• [FLINK-38894][runtime/rest] Introduce the /jobs/:jobid/rescales/history endpoint in the REST API #27705
• [FLINK-38895][runtime] Introduce the /jobs/:jobid/rescales/details/:rescaleuuid endpoint in the REST API #27695

Rescales History Tab

Rescales HistoryDetail page

Verifying this change

Reference
#27826

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): (yes / no)
• The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
• The serializers: (yes / no / don't know)
• The runtime per-record code paths (performance sensitive): (yes / no / don't know)
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes / no / don't know)
• The S3 file system connector: (yes / no / don't know)

Documentation

• Does this pull request introduce a new feature? (yes / no)
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

[flinkbot]

CI report:

• 32ee6d3 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[RocMarshal]

Hi, @och5351 Thank you for your hard work.

LGTM on the whole, just a few of comments.
PTAL in your free time :)

[RocMarshal]

• What about renaming it to JobRescaleDetails(keep the same name as backend REST part)
• What about merging the two interface into one for reusing( The corresponding class in backend is one class.)?

export interface JobRescaleDetails {
  rescaleUuid: string;
  resourceRequirementsUuid: string;
  rescaleAttemptId: number;
  vertices?: { [vertexId: string]: VertexParallelismRescaleInfo };
  slots?: { [slotSharingGroupId: string]: SlotSharingGroupRescaleInfo };
  schedulerStates?: SchedulerState[];
  startTimestampInMillis: number;
  endTimestampInMillis: number;
  terminalState: string;
  triggerCause: string;
  terminatedReason: string;
}

[och5351]

Hi @RocMarshal!

Thank you for the review :)

Regarding your first question about renaming to JobRescaleDetails:
That sounds great! I'll make that change and request your review again.

Regarding your second question about merging the two interfaces:
You make a good point. However, I think they should remain separate because they're used
for different API endpoints. JobRescaleDetails can extend JobRescaleHistory since:

• JobRescaleHistory: /jobs/:jobid/rescales/history
• JobRescaleDetails: /jobs/:jobid/rescales/details/:rescaleuuid

Does that approach work for you?

[RocMarshal]

Thanks @och5351

I compared this with the implementations of other existing frontend pages, and perhaps we can take a balanced approach.

Based on your idea, we can use inheritance to separate the two interfaces.

However, we may need to slightly differentiate the naming:

• RescalesHistory → BriefJobRescaleDetails, since “xxHistory” sounds like a collection composed of multiple objects.
• RescalesHistories → RescalesHistory, for the same reason, and it also better aligns with the abstraction level used by the backend when handling this data.
• RescalesDetailHistory → JobRescaleDetails (extends BriefJobRescaleDetails)

Pls let me know your opinon.

[och5351]

@RocMarshal
Thank you for considering my suggestions!

I agree with your naming approach. The revised names make much more sense
and better reflect the actual data structure:

• BriefJobRescaleDetails (for RescalesHistory)
• RescalesHistory (for RescalesHistories)
• JobRescaleDetails (for RescalesDetailHistory)

I'll make these changes and push a new commit for review.

Once all reviews are complete, I'll squash all the commits together.

[och5351]

Hi, @RocMarshal !
Could you please review this one more time?

Thank you.

fe05b76

[RocMarshal]

I checked UI of the PR locally with #27705.

checked:

• Refresh button related logic and correctness
• Rescales page showing logic
• The table basic information showing logic, like tooltip, table headers, columns...,etc.

LGTM +1 on the whole just a few of issues:

• highlighted in the Fig.

• When I click the Rescales/History from Rescales/Configuration page, the new Rescales/History page did not request the /jobs/:jobid/rescales/history interface， We expect that in this case, the corresponding API can be requested again.

Thanks @och5351 for the hard work.
I conducted some manual tests locally and found some minor issues, PTAL next week:)