Repository navigation
Conversation
Signed-off-by: 1fanwang <1fannnw@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TL;DR
The launch dialog and schedules panel can load slowly in projects with many workflows while their launch-plan lookups scan unrelated workflows. Both panels now use the selected workflow's full scope for an indexed lookup instead of waiting for that broader scan.
Type
Are all requirements met?
No public documentation needs changing, and no pending items remain.
Complete description
Add the workflow-side scope to both queries. Keep the existing launch-plan scope, version and active-state filters, ordering, limits, and preferred launch-plan lookup unchanged.
Tracking Issue
Related to flyteorg/flyte#6428. This covers two call sites outside the earlier fix at #891.
Follow-up issue
None.
Testing Done
The real React components ran in JSDOM through their HTTP client, public FlyteAdmin, and PostgreSQL 14.19. The catalog was registered through Admin after its normal migrations, not inserted directly into the database.
psqlscripts belowcurlanddiffbelowThis is a local PostgreSQL check, not a MySQL benchmark or a full-browser test. The original launch-dialog query already used an index, but without its leading project/domain predicates. Only the original schedule query used a sequential workflow scan in this fixture.
Setup
The backend was flyteorg/flyte@b2be54c, with PostgreSQL on
127.0.0.1:15447, databaseflytemining, userflyteprobe, and Admin on127.0.0.1:18097. Admin used memory object storage. A test-only build overlay restricted listener addresses to loopback; it did not change request handling or SQL.With that migrated local Admin running, register the project:
Save this registration script as
seed_catalog.py:Live component requests
Save this temporary probe as
packages/oss-console/src/components/Launch/LaunchForm/test/LaunchPlanQueries.live.test.tsx. It restores the real HTTP transport that the ordinary test setup stubs; the observation spy still sends every request to Admin.Run from the console checkout with its locked dependencies installed:
Before, at 04d6a33:
After:
Query plans
These are the queries captured from the two component requests. Save the original statements as
public/query-plans-before.sql:Save the scoped statements as
public/query-plans-after.sql:Before:
After:
Launch-dialog response and validation controls
The temporary live probe is not part of CI.