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

fix: wrong icm fallback is used when configured icm throws errors on SSR #1519

Merged
merged 1 commit into from
Oct 16, 2023

Conversation

Eisie96
Copy link
Contributor

@Eisie96 Eisie96 commented Oct 11, 2023

PR Type

[ x ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] CI-related changes
[ ] Documentation content changes
[ ] Application / infrastructure changes
[ ] Other:

What Is the Current Behavior?

On SSR the PWA renders a given page. It sets a transferState, which will be used on browser side afterwards. When an error for the given ICM occurs on SSR (e.g. wrong certificate), it is possible, that wrong error properties are set in state. This can lead to the problem, that JSON.stringify(state) throws an error due to the incorrect state. The outcome is, that no transferState is set on SSR. The browser side cannot retrieve the configured ICM anymore and incorrectly use the fallback (configured in environment..ts).

Issue Number: Closes #

What Is the New Behavior?

  • The error object properties in the error.reducer.ts are reduced to the defined set of the predefined HttpError interface
  • The PWA will not use a fallback for the icmBaseUrl in production mode

Does this PR Introduce a Breaking Change?

[ x ] Yes
[ ] No

No fallback for icmBaseUrl in production mode. The given option disableOption to apply configurations can be removed in order to retain the old behavior.

Other Information

AB#90030

@Eisie96 Eisie96 self-assigned this Oct 11, 2023
…allback on production mode, pwa error should only contain properties of defined HttpError interface
@shauke shauke force-pushed the fix/wrong-icm-fallback-on-error branch from c93cd9e to d556e6c Compare October 16, 2023 15:02
@shauke shauke added this to the 5.0 milestone Oct 16, 2023
@shauke shauke merged commit 8c2c203 into develop Oct 16, 2023
21 checks passed
@shauke shauke deleted the fix/wrong-icm-fallback-on-error branch October 16, 2023 15:26
shauke added a commit that referenced this pull request Nov 17, 2023
…ICM throws errors on SSR (#1519)"

* reverted: icmBaseURL no longer uses environment.ts fallback in production mode
* reverted: make usage of default/fallback configuration in environment.ts configurable for getting state properties
* refactored: errors should only contain properties of defined HttpError interface - this is now handled at the error interceptor
* kept: do not log an error that can't be stringified, it floods the log with irrelevant information

BREAKING CHANGES: No longer a breaking change regarding "No longer falls back to `environment.ts` configured `icmBaseURL` in production mode."
shauke added a commit that referenced this pull request Nov 20, 2023
…SR" (#1533)

fix: revert irrelevant changes of "wrong ICM is used when configured ICM throws errors on SSR (#1519)"

* reverted: icmBaseURL no longer uses environment.ts fallback in production mode
* reverted: make usage of default/fallback configuration in environment.ts configurable for getting state properties
* refactored: errors should only contain properties of defined HttpError interface - this is now handled at the error interceptor
* kept: do not log an error that can't be stringified, it floods the log with irrelevant information

BREAKING CHANGES: No longer a breaking change regarding "No longer falls back to `environment.ts` configured `icmBaseURL` in production mode."
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