Skip to content

Conversation

@Cerchie
Copy link
Contributor

@Cerchie Cerchie commented Dec 30, 2025

Summary of Changes

This draft adds a third dimension (files that should fail) to the artifact E2E tests.

The first thing was adding createLargeFile and cleanupLargeFile to the test utils. I chose to take the approach of creating and cleaning up the file rather than keeping it in a fixture, so the functionality belonged in utils, not fixtures.

Next, I originally implemented the matrix "entrypoint × provider/region × file size" with a triple for loop, but that felt excessive, so I mapped the entrypoints and provider regions to success/failure cases for the file size.

If you look at the invalid file dimension PR you can see that the array for file types (valid, abnormal size) is now well set up for adding the last dimension, invalid JAR files.

Note

This PR is was branched off cerchie/renaming which is now in main

%%{init: {'theme': 'base'}}%%
  gitGraph
      commit id: "103f07e9 (main)"

      branch cerchie/renaming
      checkout cerchie/renaming
      commit id: "7ae2b93346678978c9480206223f295b2b005c3b"

      branch cerchie/large-file
      checkout cerchie/large-file
      commit id: "a4740a84"

      branch cerchie/invalide-file-dimension
      checkout cerchie/invalide-file-dimension
      commit id: "ef22ed07"
Loading

Pull request checklist

Please check if your PR fulfills the following (if applicable):

Tests

  • Added new
  • Updated existing
  • Deleted existing

Release notes

  • Does anything in this PR need to be mentioned in the user-facing CHANGELOG?

artifactPath: string,
artifactsView: FlinkDatabaseView,
): Promise<string> {
const uploadedArtifactName = await artifactsView.uploadFlinkArtifact(electronApp, artifactPath);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

felt redundant

@Cerchie Cerchie requested a review from Copilot December 31, 2025 15:55
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

This PR adds test coverage for large file upload rejection in Flink artifact uploads. The changes introduce a new utility for creating large test files and extend the existing E2E test suite to verify that artifacts exceeding 100MB are properly rejected.

Key changes:

  • Added utility functions to create and cleanup large test files for testing upload size limits
  • Restructured tests to support a test matrix covering different entrypoints, cloud providers, and file sizes
  • Refactored helper functions to accept dynamic file paths instead of using hardcoded fixture paths

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File Description
tests/e2e/utils/flinkDatabase.ts New utility module providing functions to create and cleanup large test files for artifact upload testing
tests/e2e/specs/flinkArtifact.spec.ts Extended test suite with file size validation tests, restructured into test matrix pattern, and updated helper functions to accept dynamic file paths
tests/e2e/objects/views/FlinkDatabaseView.ts Renamed methods for clarity and improved documentation to better describe their purpose

const fileSizes = [
{
description: "valid size artifact",
setupFile: () => artifactPath,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

just returns a string, decided to go with an inline func for consistency with the next object in the fileSizes array

@Cerchie Cerchie changed the base branch from main to cerchie/renaming December 31, 2025 18:21
@Cerchie Cerchie changed the title DRAFT: Testing large file dimension Draft: Testing large file dimension Dec 31, 2025
@Cerchie Cerchie changed the title Draft: Testing large file dimension Draft: Testing too large file dimension Dec 31, 2025
// Swallow any errors from the upload flow since we expect failure
}

await expect(artifactsView.artifacts).toHaveCount(initialArtifactCount);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

we assert based on the artifact count, because the name will never have been created at this point, so it will always not be found

@@ -0,0 +1,54 @@
import * as fs from "fs";
Copy link
Contributor Author

@Cerchie Cerchie Dec 31, 2025

Choose a reason for hiding this comment

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

new file, will also set the stage for adding a util that create an invalid JAR file for the next dimension

@Cerchie Cerchie changed the title Draft: Testing too large file dimension Testing too large file dimension Dec 31, 2025
// /* no cleanup needed for fixture file */
// },
// shouldSucceed: true,
// },
Copy link
Contributor Author

Choose a reason for hiding this comment

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

only one for now, but see the next PR

Base automatically changed from cerchie/renaming to main January 2, 2026 15:46
* @param electronApp - The Electron application instance
* @param filePath - The path to the JAR file to upload
* @param skipInitiation - If true, skips clicking the upload button (assumes quickpick is already open)
* @param expectSuccess - If true, waits for success notification; if false, caller handles error notification
Copy link
Contributor Author

Choose a reason for hiding this comment

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

added since we now expect failures sometimes

@Cerchie Cerchie marked this pull request as ready for review January 2, 2026 19:09
@Cerchie Cerchie requested a review from a team as a code owner January 2, 2026 19:09
{
entrypoint: SelectFlinkDatabase.DatabaseFromResourcesView,
testName: "should upload Flink Artifact when cluster selected from the Resources view",
testName: "cluster selected from the Resources view",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

not successful every time now

@shouples shouples self-assigned this Jan 5, 2026
Copy link
Contributor

@shouples shouples left a comment

Choose a reason for hiding this comment

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

Good progress overall! I'm mainly concerned about the expectSuccess usage requiring some mental gymnastics to follow the test flow/logic and think it could be simplified a bit, and then (to a lesser extent) any lingering big .jar files that are created but not explicitly cleaned up. We can address those in a near-term follow-up though.

Comment on lines +369 to +376
if (expectSuccess) {
// Wait for upload success notification
const notificationArea = new NotificationArea(this.page);
const successNotifications = notificationArea.infoNotifications.filter({
hasText: "uploaded successfully",
});
await expect(successNotifications.first()).toBeVisible();
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Doesn't have to be in this branch, but I think we should move these out into the individual tests themselves so too much test-logic isn't inside of these page object models.

provider,
region,
pathToBigArtifact,
false, // expectSuccess - we expect this upload to fail
Copy link
Contributor

Choose a reason for hiding this comment

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

This feels a little odd - what errors do we expect here? It may be clearer to expect the error notification instead of handling the failed info-notification assertion

*/
export function createLargeFile(options: LargeFileOptions = {}): string {
const {
sizeInMB = 101,
Copy link
Contributor

Choose a reason for hiding this comment

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

Minor: it may be clearer to set the size limit the extension uses as a top-level constant here, then just increment by 1 to indicate exceeding the size

Suggested change
sizeInMB = 101,
sizeInMB = MAX_ARTIFACT_FILE_SIZE_MB + 1, // just over the limit to trigger error notification

@Cerchie Cerchie merged commit ea83fc1 into main Jan 7, 2026
14 checks passed
@Cerchie Cerchie deleted the cerchie/large-file branch January 7, 2026 17:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants