Skip to content

(chore): Added early error message for configuration error#14222

Closed
yuhengshs wants to merge 12 commits intomainfrom
feat-amplify/error
Closed

(chore): Added early error message for configuration error#14222
yuhengshs wants to merge 12 commits intomainfrom
feat-amplify/error

Conversation

@yuhengshs
Copy link
Contributor

@yuhengshs yuhengshs commented Feb 18, 2025

Description of changes

The purpose of this PR is to add early error message when Amplify.configure() is not called, an error will be thrown early to the customers and notify them Amplify.configure() is not called.
Unit test is added accordingly.

Issue #, if available

Description of how you validated changes

Checklist

  • PR description included
  • yarn test passes
  • Unit Tests are changed or added
  • Relevant documentation is changed or added (and PR referenced)

Checklist for repo maintainers

  • Verify E2E tests for existing workflows are working as expected or add E2E tests for newly added workflows
  • New source file paths included in this PR have been added to CODEOWNERS, if appropriate

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@yuhengshs yuhengshs marked this pull request as ready for review February 19, 2025 16:38
@yuhengshs yuhengshs requested review from a team, HuiSF, ashika112 and cshfang as code owners February 19, 2025 16:38
Copy link
Contributor

@stocaaro stocaaro left a comment

Choose a reason for hiding this comment

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

The amount of change here makes me wonder if we're not missing something. How do we know that we haven't missed protecting a call site that uses config? Since this is spread over all of the categories independently, are we retesting all categories to ensure this behaves as expected in each case?

import { DEFAULT_KINESIS_FIREHOSE_CONFIG } from './constants';

export const resolveConfig = () => {
Amplify.assertConfigured();
Copy link
Contributor

Choose a reason for hiding this comment

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

Quite a few of these occur right before we call Amplify.getConfig(). Do we always want to assert configured with getConfig? If so, could we include this in the getConfig behavior to remove some of the amount of change happening here?

Also, there are a number of places where this isn't couple with getConfig. This seems counterintuitive, right? Are these other callsites still calling getConfig, but a few layers of abstraction removed? Is there a pattern for accessing the config different from using getConfig?

@soberm
Copy link
Contributor

soberm commented Jul 29, 2025

Closed in favor of #14424

@soberm soberm closed this Jul 29, 2025
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