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

Root out legacy upload APIs from the test-utils reporter #606

Merged
merged 13 commits into from
Jul 11, 2024

Conversation

Andarist
Copy link
Member

@Andarist Andarist commented Jul 8, 2024

I noticed that we removed the file related to multipart upload from the files that we ported to test-utils. Luckily, we also forgot to initialize LD... so those code paths were never hit here (cc @callingmedic911 ).

This sparked a further refactor to get rid of the legacy uploading code from the test-utils and to use the one that we have in /shared.

Copy link

changeset-bot bot commented Jul 8, 2024

⚠️ No Changeset found

Latest commit: 22b5d6e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link

replay-io bot commented Jul 8, 2024

Status Complete ↗︎
Commit 81831d1
Results
2 Failed
  • clicks a disappearing button
  • should fail on this test
  • 42 Passed
  • adds items
  • adds new items using a custom command
  • adds todos following the fixture
  • adds todos following the fixture
  • adds todos following the fixture
  • adds todos following the fixture
  • calls inform
  • complete all checkbox should update state when items are completed / cleared
  • gets a number
  • only gets a number
  • only gets a number
  • should allow me to add todo items
  • should allow me to clear the complete state of all items
  • should allow me to display active items
  • should allow me to display all items
  • should allow me to display completed items
  • should allow me to edit an item
  • should allow me to mark all items as completed
  • should allow me to mark items as complete
  • should allow me to un-mark items as complete
  • should append new items to the bottom of the list
  • should be hidden when there are no items that are completed
  • should cancel edits on escape
  • should clear text input field when an item is added
  • should display the correct text
  • should display the current number of todo items
  • should focus on the todo input field
  • should hide #main and #footer
  • should hide other controls when editing
  • should highlight the currently applied filter
  • should intercept postman
  • should invoke some commands that have exceptional option handling
  • should log
  • should persist its data
  • should remove completed items when clicked
  • should remove the item if an empty text string was entered
  • should respect the back button
  • should save edits on blur
  • should show #main and #footer when items added
  • should trim entered text
  • should trim text input
  • yields a number
  • @Andarist
    Copy link
    Member Author

    Andarist commented Jul 8, 2024

    /release-pr

    @Andarist Andarist marked this pull request as ready for review July 8, 2024 13:06
    packageName,
    packageVersion,
    });

    if (accessToken) {
    initLaunchDarklyFromAccessToken(accessToken);
    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 is async but we can't even await things here, this is race'y. But what should be done about it - should getFeatureFlagValue await the pending identification?

    Copy link
    Contributor

    Choose a reason for hiding this comment

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

    Hmm... initLaunchDarklyFromAccessToken is async because it fetches auth info.

    The reporter base class (in test-utils) already awaits auth info in order to initialize the Grafana logger. Should we move LD initialization in there?

    should getFeatureFlagValue await the pending identification?

    It already does :) That's how I designed it.

    Copy link
    Member Author

    Choose a reason for hiding this comment

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

    Hmm... initLaunchDarklyFromAccessToken is async because it fetches auth info.

    The same is true about MixPanel's initialization - both should get the same treatment here.

    The reporter base class (in test-utils) already awaits auth info in order to initialize the Grafana logger. Should we move LD initialization in there?

    I'll look into this.

    It already does :) That's how I designed it.

    It waits on the LD's initialization - but is this the same as the user's identification? 🤔

    Copy link
    Contributor

    Choose a reason for hiding this comment

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

    Perhaps I misremembered what it's doing 😆 You're right. I think waiting some small amount (before falling back to the default user profiles) seems reasonable?

    .changeset/silver-geckos-smoke.md Outdated Show resolved Hide resolved
    packageName,
    packageVersion,
    });

    if (accessToken) {
    initLaunchDarklyFromAccessToken(accessToken);
    Copy link
    Contributor

    Choose a reason for hiding this comment

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

    Hmm... initLaunchDarklyFromAccessToken is async because it fetches auth info.

    The reporter base class (in test-utils) already awaits auth info in order to initialize the Grafana logger. Should we move LD initialization in there?

    should getFeatureFlagValue await the pending identification?

    It already does :) That's how I designed it.

    @bvaughn
    Copy link
    Contributor

    bvaughn commented Jul 10, 2024

    RE: the changes to initLaunchDarklyFromAccessToken – I'm going to re-think this stuff as part of PRO-797

    (Not that it should necessarily impact this PR, just an FYI)

    @Andarist
    Copy link
    Member Author

    RE: the changes to initLaunchDarklyFromAccessToken – I'm going to re-think this stuff as part of PRO-797

    Ye, I reverted the LD-related changes from this PR as it wasn't completely obvious how it should work. I'll lean on PRO-797 to improve this

    @Andarist Andarist requested a review from bvaughn July 10, 2024 15:22
    @Andarist Andarist merged commit a57c6e7 into main Jul 11, 2024
    7 checks passed
    @Andarist Andarist deleted the root-out-legacy-upload branch July 11, 2024 12:02
    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.

    2 participants